Sistemas Distribuídos

Sistemas Distribuídos
Francisco Brasileiro Aula 4: Tolerância a Falhas em Sistemas Distribuídos

Agenda Motivação Conceitos básicos e definições Mecanismos básicos
Acordo Bizantino Sincronização de relógios Armazenagem estável Entrega confiável de mensagens Nodos com semântica de falha controlada b) Artigos clássicos Laprie, J-C., “Dependability: a Unifying Concept for Reliable Computing and Fault Tolerance”, em Dependability of Resilient Computers, pp (também em Digest of Papers of FTCS-15, pp. 2-11). Lamport, L., “Time, Clocks, and the Ordering of Events in a Distributed System”, CACM 21(7), pp , julho de 1978. Cristian, F., “Understanding Fault-Tolerant Distributed Systems”, CACM 34(2), pp , fevereiro 1991. Schneider, F.B., “Implementing Fault-Tolerant Services Using the State Machine Approach: A Tutorial”, ACM Computing Surveys 22(4), pp , dezembro 1990. Lamport, L., Shostak, R. e Pease, M., “The Byzantine Generals Problem”, ACM TOPLAS 4(3), pp , julho 1982. c) Periódicos de interesse ACM TOPLAS, TODS, TOCS IEEE TC, TSE, TPDS Distributed Computing Edições especiais (ACM Computing Surveys junho/81, IEEE Computer julho/90, IEEE TC maio/92, IEEE TC maio/94, entre outros)

Motivação Necessidade de tolerância a faltas
aumento do uso de computadores diversificação do uso de computadores aumento da dependência no correto funcionamento dos sistemas computacionais

Motivação Exemplos de aplicações com requisitos de confiança no funcionamento Sistemas críticos envolvendo risco de vida controle de vôo em aeronaves Sistemas envolvendo perdas financeiras transações bancárias e do mercado financeiro Sistemas envolvendo desastres ambientais controle de usinas nucleares Exemplos de aplicações com requisitos de confiança no funcionamento: - Sistemas de controle de vôo para aeronaves objetivam diminuir o custo do vôo, através do uso de um “piloto” extremamente preciso em suas manobras, e mais confiável; - Sistemas de monitoração hospitalar objetivam diminuir o risco de vida de pacientes internados em unidades de terapia intensiva, através do controle preciso e em tempo-real, de um grande número de parâmetros; Outros sistemas críticos envolvendo risco de vida ou grandes perdas financeiras são: sistema de lançamento e controle de mísseis, controle de tráfego aéreo, controle de processos industriais, transações bancárias e do mercado financeiro, etc. Sistemas de controle de centrais telefônicas digitais são exemplos de sistemas com requisitos de alta disponibilidade.

Motivação Quando é que um sistema falha?
Qual é o serviço adequado de um sistema? Vamos assumir que a especificação é correta Importância de se tratar faltas em sistemas distribuídos em um sistema distribuído a probabilidade de um componente falhar é maior aplicações críticas

Conceitos Básicos e Definições
Serviços de um sistema computacional Confiança no funcionamento (dependability) Atributos de confiança no funcionamento Fiabilidade (reliability) Disponibilidade (availability) Segurança prevenção contra catástrofes (safety) prevenção contra acesso não autorizado (security) O serviço oferecido por um sistema computacional é o seu comportamento, conforme percebido pelo(s) seu(s) usuário(s). Pode ser adequado, quando é fornecido de acordo com a especificação; ou inadequado, quando o serviço oferecido é diferente do especificado. Um usuário é um outro sistema (humano ou mecânico), que interage com o sistema considerado. A confiança no funcionamento de um sistema computacional é definida pelos predicados que o sistema tem, de forma a justificar que se acredite na fiabilidade dos serviços que ele provê. Confiança no funcionamento é um conceito global que engloba um número de atributos. Dependendo da natureza da aplicação, um determinado atributo pode ser mais ou menos enfatizado. Os principais atributos da confiança no funcionamento são: - fiabilidade: é uma medida do contínuo fornecimento do serviço adequado, ou de forma equivalente, do tempo para falha; - Disponibilidade: é uma medida do fornecimento do serviço adequado, com respeito à alternância entre serviço adequado e inadequado; - Segurança: é uma medida da capacidade do sistema de prevenir catástrofes (safety) e acesso não autorizado (security).

Tratamento de faltas Prevenção minimizar, por construção, a probabilidade da ocorrência de faltas Tolerância prover o serviço, ainda que ocorram faltas introduz redundância no sistema física temporal As técnicas para prevenção de faltas são normalmente aplicadas à fase de manufatura do sistema, e às condições ambientais às quais o sistema será exposto. A utilização de uma metodologia de projeto conservadora e de componentes de altíssima qualidade, além de uma busca da redução da complexidade do sistema e a execução exaustiva de testes na fase de projeto, reduzem a probabilidade de faltas no sistema. Além disso, quando o sistema está operacional, um controle sobre variáveis ambientais (temperatura, flutuações da alimentação, interferência humana, etc.), podem reduzir ainda mais a probabilidade de faltas. Infelizmente, o uso indiscriminado de componentes de alta qualidade pode impactar imensamente o custo do sistema. Outro problema é que nem sempre é possível controlar o ambiente de execução do sistema. Uma abordagem mais factível é prever os tipos de faltas que podem ocorrer e introduzir redundância para tratá-las.

Características de prevenção de faltas ausência de redundância falhas ocasionais do sistema manutenção assistida por humanos Problemas com a abordagem atraso longo quando há necessidade de reparo possível inacessibilidade para efetuar reparo custos excessivos na manutenção e com o processamento perdido Aplicações críticas com requisitos tempo-real não aceitam os longos atrasos incorridos na manutenção de sistemas baseados em prevenção de faltas. Alguns sistemas (ex. missões espaciais, satélites, sondas submarinas, manipuladores de substancias tóxicas), não permitem a manutenção do sistema através de humanos.

Combinando prevenção e tolerância As duas técnicas são complementares Algumas aplicações devem necessariamente tolerar faltas A introdução de redundância física possibilita a substituição do reparo manual Outros pontos importantes diagnóstico de faltas validação dos mecanismos do sistema para tolerância a faltas A maioria dos sistemas tolerantes a faltas utilizam tanto prevenção como tolerância a faltas. as duas técnicas são complementares. Concentraremos nossos estudos em tolerância a faltas.

Modelando sistemas Visão externa Visão interna Comportamento do sistema Especificação de serviços Características desejáveis em uma especificação completa consistente correta Um sistema deve interagir com o ambiente no qual ele está inserido. O comportamento externo do sistema é observado pelo ambiente através da interface do sistema. O ambiente externo pode ser dividido em sub-ambientes, de acordo com os pontos de maior interesse para o sistema. Um sistema é composto internamente por uma coleção sub-sistemas que por sua vez são compostos de outros sub-sistemas, até que se chegue a um nível onde não é mais possível ou interessante subdividir o componente. Estes componentes são ditos atômicos. Os estados internos dos sub-sistemas definem o estado externo, ou comportamento, do sistema. O comportamento do sistema pode ser adequado, quando está de acordo com a sua especificação, ou inadequado, quando o mesmo se afasta do comportamento especificado. Uma especificação define o serviço esperado para o sistema, o qual é observado através das saídas e interações entre os sub-sistemas. Uma especificação deve ser completa, consistente e correta.

Falha ou defeito (failure) Desvio da especificação Erro (error) Estado ou transição interna ilegais Falta (fault) Causa dos erros e falhas Relação entre falta, erro e falha

Tipos de faltas Quanto à duração permanentes, transientes, intermitentes Quanto à natureza físicas, interação Quanto à fase de introdução projeto, operação

Semântica de falha de componentes domínio do valor domínio do tempo tipos de falhas silenciosa (crash, fail-stop) omissão temporização (desempenho) valor arbitrária (Bizantina) Bizantina com autenticação

Sistemas tolerantes a faltas Evitam a falha do sistema, mesmo na presença de faltas em alguns dos componentes do sistema Mesmo que alguns componentes falhem, o sistema ainda é consistente com a sua especificação redução de desempenho (graceful degradation) Introdução de redundância é o princípio básico Através do uso de redundância, mascara, ao nível do sistema, as falhas que um número finito de seus sub-sistemas, ou componentes, podem apresentar.

Fases na tolerância a faltas Detecção de erros Contenção e avaliação de estragos Recuperação de erros Tratamento de faltas e continuidade do serviço diagnóstico de faltas reconfiguração do sistema

Detecção de erros Dedução de faltas e falhas Propriedades de um detetor de erros ideal completude e corretude independência de projeto Principais tipos de detetores de erros replicados temporizadores (watchdogs) códigos e redundância estrutural testes de aceitação e diagnósticos

Contenção e avaliação de estragos Latência Disseminação de erros Análise do fluxo de informação Portas “corta-fogo” SRU’s (smallest replacement units)

Recuperação de erros Abordagem pessimista (backward recovery) pontos de salvaguarda (checkpoint) implementação razoavelmente simples custo alto efeito “dominó“ Abordagem otimista (forward recovery) ações corretivas considerações sobre a natureza dos erros normalmente é dependente da aplicação ou do sistema

Tratamentos de faltas e continuidade do serviço Identificação de componentes defeituosos Localização do erro Reparo do sistema on-line reconfiguração componentes suplentes (spares) passivos (cold-spares) e ativos (hot-spares)

Modelagem de sistemas distribuídos Modelo físico Principais componentes processadores rede de comunicação dispositivos de armazenagem não voláteis software Modelo lógico Aplicações implementadas por processos cooperantes Comunicação via troca de mensagens Sistemas síncronos versus sistemas assíncronos Um sistema distribuído consiste de vários nodos, cada nodo consistindo tipicamente de um processador, que tem uma memória volátil privada, um relógio local, uma ou mais interfaces para a rede de comunicação, e possivelmente alguns dispositivos de entrada/saída. Além disso, existe o software que especifica a seqüência de instruções a ser executada pelo nodo. Freqüentemente um sistema distribuído é modelado através de seus nodos e de suas inter-conexões, apenas. Neste modelo, as faltas consideradas, são aquelas que afetam os nodos e os canais de comunicação.

Tipos de sistemas distribuídos Sistemas síncronos atraso máximo conhecido para escalonamento e troca de mensagens oferecem framework mais simples mais difíceis de serem implementados Sistemas assíncronos timed-related x time-free mais fáceis de serem implementados

Mecanismos Básicos Suportes para construção de sistemas distribuídos tolerantes a faltas Como disseminar informação de forma consistente e confiável? Como ordenar eventos? Como prover um sistema de tempo global? Como armazenar informação de forma estável? Como restringir a semântica de falha de componentes? A maioria dos mecanismos existentes para tolerância a faltas fazem considerações sobre o comportamento do sistema, e sobre os seus modos de falha. Vamos estudar formas de suportar as considerações comumente feitas. Entre estas construções podemos destacar: - Acordo Bizantino - Sincronização de relógios - Armazenagem estável - Entrega confiável de mensagens - Nodos com semântica de falha controlada

Mecanismos Básicos: Acordo Bizantino
Como atingir consenso na presença de componentes com semântica de falha arbitrária? O problema dos generais Bizantinos decisão final é baseada nas decisões locais alguns generais podem ser traidores Como garantir que todos os generais leais decidirão pelo mesmo plano? os generais devem receber as mesmas informações os generais devem usar a mesma função de decisão O termo falha Bizantina foi introduzido por Lamport, Shostak e Pease, no famoso artigo “The Byzantine Generals Problem”, onde o problema de se concordar sobre um valor disseminado por um componente em um sistema distribuído onde componentes podem falhar de forma arbitrária, é discutido. Naquele artigo, os autores usam a abstração de um cerco de divisões da armada Bizantina a uma cidade inimiga, e a tentativa de fazer os generais das armadas concordarem numa estratégia comum, mesmo quando alguns dos generais são traidores. A necessidade de se chegar a um consenso em um sistema distribuído é uma das operações mais comuns quando se implementa mecanismos para tolerância a faltas. De fato, acordo Bizantino pode ser considerado como um bloco fundamental na construção de mecanismos para tolerância a faltas em sistemas cujos componentes podem apresentar uma semântica de falha arbitrária. De uma forma abstrata, o problema pode ser definido da seguinte forma: várias divisões da armada Bizantina estão acampadas ao redor de uma cidade inimiga. Cada divisão comandada pelo seu próprio general, que usa mensagens para trocar informações com os outros generais. Depois de observar o inimigo, eles devem tomar uma decisão sobre um plano de ação comum.

Como entrar em um acordo sobre qual valor usar para a decisão de um general traidor? Todos os generais leais devem chegar a um consenso sobre que valor usar para a decisão de cada general Consistência interativa todos os generais leais usam o mesmo valor v(i) para o general i se o general i é leal, então todos os generais leais devem usar o valor v(i) que o general i envia Os generais devem executar um algoritmo que garanta que todos os generais leais decidirão no mesmo plano de ação. Isso pode ser garantido se eles recebem as mesmas informações e aplicam a mesma função de decisão. O problema se complica pelo fato de um traidor poder enviar informação inconsistente. O que temos que garantir é que todos os generais leais usem a mesma informação para cada outro general, ou seja, todos os generais leais devem chegar a um consenso sobre que valor usar para a decisão de cada general. Esse problema é também chamado de consistência interativa e pode ser formalmente definido da seguinte forma: 1. Todos os generais leais usam o mesmo valor v(i) para o general i; e 2. Se o general i é leal, então todos os generais leais devem usar o valor v(i) que o general i envia. Note que soluções para esse problema devem levar em consideração que o transmissor (o general i) pode ser traidor.

Requisitos para obter consistência interativa Várias rodadas de troca de informação Sistema de comunicação síncrono Número limitado de generais traidores Há solução para o caso de 3 generais, onde um deles pode ser um traidor? os generais podem tomar apenas duas decisões (atacar ou esperar) É necessário saber qual informação o general i passou para os outros generais, e confrontar esse valor com a informação recebida de i. O problema fica mais complexo porque as mensagens repassadas também não são confiáveis. De forma que o problema só tem solução se existe um número limitado de generais traidores. Se o sistema é assíncrono, o problema não tem solução. Um general traidor pode simplesmente não enviar qualquer informação.

G1 (T) atacar atacar G2 (R) G3 (R) esperar O que fazer?

G1 (T) atacar esperar G2 (R) G1 (R) esperar O que fazer?

Resultados teóricos Número mínimo de rodadas k+1 Relação mínima entre componentes corretos/defeituosos n/k>3 Número mínimo de canais de comunicação disjuntos 2k+1

Algoritmo recursivo para consistência interativa ICA(k), k>0 1. O transmissor envia o seu valor para os outros n-1 receptores 2. Seja v o valor recebido pelo general i, ou o valor default se nada for recebido. O general i se comporta como transmissor no algoritmo ICA(k-1) para enviar v para os outros n-2 receptores 3. Para cada general i, seja vj o valor recebido de j (i¹¡). O general i usa o valor da maioria dos valores recebidos para i ICA(0) 1. O transmissor envia seu valor para os outros n-1 receptores 2. Cada general usa o valor recebido do transmissor ou o valor default se nada for recebido

Consistência interativa com mensagens assinadas Mensagens repassadas por generais traidores não podem ser modificadas sem que isso seja detectado por generais leais assinaturas digitais Resultados teóricos número de rodadas: k+1 número máximo de generais traidores: n>k número de canais de comunicação disjuntos: k+1

Mecanismos Básicos: Sincronização de Relógios
Como estabelecer um referencial de tempo global em um sistema distribuído? Cada nodo tem seu relógio local Relógios desviam do tempo real Tempo global e ordenação de eventos relógios lógicos sincronização de relógios sincronização interna sincronização externa Em um sistema distribuído cada nodo tem seu próprio relógio. Estes relógios naturalmente diferem uns dos outros, e também se desviam do tempo real. relógios lógicos podem ser usados para definir uma ordem parcial de um conjunto de eventos. Embora esta ordenação parcial possa ser estendida para uma ordenação total, esta não tem necessariamente qualquer relação com uma ordenação baseada em uma noção de tempo global. Para que isso seja possível, é necessário sincronizar os relógios do sistema. Sincronização pode ser interna ou externa. Na sincronização externa dos relógios, estes devem ser mantidos dentro de um limite máximo de desvio em relação a um referencial de tempo externo ao sistema (ex. tempo “real”). A sincronização interna, requer que os relógios do sistema sejam mantidos dentro de um limite máximo de desvio entre eles. A sincronização externa implica na sincronização interna, mas a sincronização interna não implica na externa. Sincronização interna pode ser usada para medir a duração de atividades distribuídas, enquanto que a sincronização externa pode ser necessária em sistemas tempo-real, onde se deseja especificar o tempo real para a ocorrência de um evento.

A relação “aconteceu antes” (Ô) e a ordenação de eventos Para dois eventos a e b: se a e b são eventos no mesmo processo e a vem antes de b, então a Ô b se a é o evento de envio de uma mensagem m e b é o evento de recepção de m, então a Ô b se existe um terceiro evento c, tal que a Ô b e b Ô c, então a Ô c

Relógios lógicos implementam a relação “Ô” Um relógio lógico é um contador que serve para associar valores a eventos e cada processo tem um relógio lógico Ci<a> é o valor associado ao evento a pelo processo i onde a ocorreu Para dois eventos a e b: se a Ô b, então C(a) < C(b) Como implementar relógios lógicos? Relógio é incrementado entre dois eventos locais Mensagens carregam estampilhas

Aspectos a serem considerados na sincronização de relógios físicos Relógios corretos operam em diferentes velocidades Necessidade de re-sincronização periódica Troca de mensagens com valores das leituras dos relógios introduz incerteza Falhas nos relógios e nos canais de comunicação Algumas aplicações distribuídas necessitam que os relógios do sistema estejam sincronizados. Em alguns casos, mesmo que tolerância a faltas não seja um requisito, ainda assim os relógios precisam ser sincronizados. Alguns dos mecanismos básicos que serão discutidos mais a frente, necessitam que os relógios do sistema sejam sincronizados. O problema de sincronizar relógios tem vários aspectos. Além dos relógios puderem estar lendo valores diferentes, eles podem medir o tempo em diferentes velocidades. Isso introduz a necessidade de realizar a sincronização de forma periódica. Qualquer tentativa de sincronização de relógios implica na necessidade dos relógios trocarem informações sobre seus valores, o que só pode ser feito através da rede de comunicação, a qual é responsável pela introdução de incerteza no valor lido, devido ao tempo variável para transmissão de mensagens. O maior problema entretanto é a possibilidade de ocorrência de faltas nos relógios e no meio de comunicação.

Definição do problema: Sejam Ci(t) a leitura de Ci no tempo real t e ci(T) o tempo real quando o i-ésimo relógio lê o valor T assumindo que os relógios são contínuos: para um relógio correto, |d(Ci/dt)-1| < r existem dois requisitos básicos para sincronização de relógios: a todo instante a leitura de dois relógios corretos deve ser bastante próxima (|Ci(t)-Cj(t)| £ b) um relógio correto só pode ser adiantado/atrasado de um intervalo de tempo pequeno e limitado, durante cada re-sincronização Assumimos que os relógios são contínuos, embora na prática, qualquer implementação de um relógio físico é discreta. Para um relógio correto, existe um valor r que define o desvio máximo que um relógio correto pode ter em relação ao tempo real. Com a tecnologia atual, r é da ordem de 10-5.

Tipos de protocolos Determinísticos sempre garantem a precisão da sincronização assumem um limite máximo no atraso para a transmissão de mensagens Probabilísticos nenhuma restrição sobre o atraso na troca de mensagens garantem a precisão da sincronização apenas dentro de uma probabilidade pré-definida Os protocolos para sincronização de relógios podem ser classificados em duas grandes categorias: os protocolos determinísticos e os probabilísticos. Nos protocolos determinísticos os relógios são garantidamente sincronizados dentro dos limites especificados. Entretanto, esses protocolos assumem um limite no atraso para transmissão de mensagens, ou seja, assumem um sistema síncrono. Protocolos probabilísticos por sua vez podem ser implementados em sistemas assíncronos, porém eles só garantem os limites de sincronização dentro de uma probabilidade pré-definida, geralmente menor que 100%.

Protocolos determinísticos Uma possível solução é: cada nodo lê o seu relógio e o relógio dos outros nodos atribui ao seu relógio a mediana dos valores lidos Em que circunstâncias esse protocolo funciona? a maioria dos nodos (e seus relógios) são corretos nodos e relógios não sofrem falhas arbitrárias O que fazer na presença de falhas arbitrárias? dois nodos corretos quaisquer devem obter (aproximadamente) o mesmo valor para um relógio Ci se Ci é correto, o valor obtido é o valor de Ci Uma abordagem possível para a sincronização de relógios determinística é que cada nodo leia o relógio de todos os nodos do sistema (inclusive o seu) e utilize o valor da mediana dos valores lidos como sendo o novo valor de seu relógio. Se apenas uma minoria dos relógios são incorretos, essa abordagem pode funcionar. Entretanto, devido à possibilidade de faltas arbitrárias (em especial, no caso de relógios, o conhecido comportamento duplo - dual-phased clocks), não se pode usar como leitura de um relógio o valor recebido diretamente dele. Para que essa abordagem funcione é necessário que todos os nodos entrem em consenso sobre que valor usar para o relógio de cada nodo do sistema. Note que esse problema é bastante parecido com o problema da obtenção de consistência interativa, estudado anteriormente, e portanto, soluções e resultados teóricos similares podem ser facilmente derivadas daquelas previamente discutidas.

Uma solução com mensagens orais Número de nodos é pelo menos 3k+1 C(t)=H(t)+CORR(t) Inicialmente os relógios estão sincronizados em e Existe dmin e dmax para o atraso na transmissão Quando Ci(t)=T o nodo i dissemina “a hora é T” Guarda tempo das recepções de mensagens dos outros nodos por um período de (e+dmax)(1+r) Com os tempos de recepção recalcula CORR(t) joga fora os k maiores e os k menores CORR(t)=d + mediana dos valores restantes O algoritmo é executado em rodadas da seguinte forma: a rodada i é desencadeada quando o relógio local atinge um valor Ti previamente estabelecido. A rodada i+1 será desencadeada quando o relógio local atingir o valor Ti+DT, onde DT é o intervalo de re-sincronização. Quando o relógio local atinge um valor Ti, o nodo dissemina mensagens para todos os nodos do sistema informando que a hora local é Ti, e aguarda mensagens desta rodada dos outros nodos por um período de tempo de (b+d+e)(1+r) unidades de tempo, guardando o tempo de recepção de cada mensagem. Usando os tempos de recepção das mensagens, o nodo calcula um novo valor para CORR(t). Para evitar que relógios incorretos possam comprometer a sincronização dos relógios corretos, CORR(t) é calculado da seguinte forma: joga-se fora os k maiores e os k menores valores do tempo de recepção. Calcula-se então a mediana dos k+1 valores restantes. A idéia é que no pior caso os valores correspondentes aos relógios corretos estarão no meio da série ordenada de valores recebidos. Desta forma, descartando-se os k valores maiores e menores, elimina-se a influência dos valores dos relógios incorretos.

Protocolos probabilísticos Algoritmo de Cristian tolera falhas de desempenho não assume atraso máximo, mas assume um atraso mínimo nodo j requisita o valor do relógio de um nodo i e corrige esse valor com base no atraso de leitura Para ler o relógio de um outro nodo, um nodo manda uma mensagem requisitando o tempo local naquele nodo e espera pela resposta. Com base no tempo de resposta (round trip delay) 2D, o tempo enviado na mensagem e o tempo mínimo de transmissão de uma mensagem, o nodo requisitante faz uma estimativa do tempo do outro nodo no momento da recepção da mensagem. Este valor é utilizado para sincronizar o relógio local com o relógio do nodo remoto.

Protocolos probabilísticos Algoritmo de Cristian seja T o valor do relógio i quando a requisição de j é recebida e 2D o tempo de transmitir o pedido para i e receber a resposta: quando j recebe a mensagem o relógio de i lê um valor no intervalo [T+dmin(1-r), T+2D(1+2r)-dmin(1+r)] o valor médio do intervalo minimiza o erro o erro máximo dá a precisão da leitura quanto menor D maior a precisão para uma precisão e é preciso descartar todas as leituras com atraso maior que 2U, onde U=(1-2r)(e+dmin)

Mecanismos Básicos: Armazenagem Estável
Qual a necessidade de se ter armazenagem estável? Ter acesso à informação depois que uma falha ocorre uso de dispositivos de armazenagem não voláteis Recuperação para trás leitura de pontos de salvaguarda Aumentar a fiabilidade de discos “de prateleira” É freqüente a necessidade de garantir que as informações armazenadas em meios não voláteis possam ser acessíveis, mesmo depois que falhas ocorram, isto é, que o conteúdo armazenado não seja destruído ou corrompido. Embora dados armazenados em discos sejam não voláteis, e normalmente sobrevivam a quedas do servidor e faltas de energia, nem sempre é possível considerá-los como um meio de armazenagem confiável. Para sistemas com requisitos mais restritivos, não se pode assumir que discos comuns ofereçam armazenagem estável. É preciso portanto, implementar mecanismos que possam justificar essa consideração.

Definição do problema Toda informação que é gravada com sucesso no tempo T, pode ser lida no tempo T’, T’>T mesmo que falhas ocorram durante a operação mesmo que os dispositivos sofram faltas físicas Cada bloco do disco tem um valor e um estado o estado pode ser correto ou defeituoso Primitivas básicas de acesso ao disco write(endereço, dado), retorna sucesso ou fracasso read(endereço), retorna (estado, valor) O problema básico é adicionar hardware e software a uma unidade de armazenagem convencional, de forma que as aplicações que têm acesso às informações armazenadas na unidade, possam tratá-la como sendo estável, independente da possibilidade de alguns componentes falharem. Para entender o problema é necessário primeiro entender os possíveis modos de falha dos componentes. Cada bloco do disco tem associado a si um valor e um estado, o qual pode assumir os valores correto ou defeituoso.

Como tratar faltas em discos? A maior parte pode ser tratada por meio de codificação Algumas faltas não podem ser tratadas assim falta transiente setor defeituoso falha da controladora falha do disco Existem vários tipos de faltas possíveis em um disco. Muitos dos erros gerados são tratados com sucesso através de técnicas de codificação. Algumas faltas, entretanto, não podem ser tratados por tais técnicas. As principais são: - Faltas transientes: causam um comportamento imprevisível do disco, por um período curto de tempo; - Setor defeituoso: um bloco se torna defeituoso, e o dado armazenado lá não pode ser lido (isto pode ocorrer devido a razões físicas, por exemplo, sujeira na trilha); - Falha na controladora: a controladora do disco falha, devido a problemas no hardware da controladora, ou queda do nodo ao qual a controladora está conectada (o conteúdo do disco não é corrompido, mas fica inacessível até que reparos sejam executados); - Falha do disco: não se pode ler nenhum bloco do disco; esse tipo de falha pode ocorrer quando o hardware do disco falha (ex. aterrissagem do cabeçote de leitura/gravação).

Tratando os efeitos das faltas Ao invés de enumerar todas as possíveis faltas, é melhor estudar o impacto das mesmas prover métodos para esconder/reverter os erros Eventos que ocorrem em um disco leitura, gravação e espontâneos desejáveis e não desejáveis É preciso mascarar os efeitos de eventos não desejáveis Existem outras possibilidades de falhas para um disco. Ao invés de enumerar todas as razões para as possíveis faltas em um disco, e acharmos maneiras de tolerá-las, podemos estudar o impacto da manifestação dessas faltas no comportamento do disco, e prover métodos para esconder ou reverter os erros gerados. Os eventos que ocorrem em um disco são aqueles resultantes de uma operação de leitura ou gravação, e alguns eventos espontâneos. esses eventos podem ser desejáveis ou não. Queremos construir unidades de armazenagem estável que mascarem os efeitos dos eventos não desejáveis.

Eventos indesejáveis da operação read Erro temporário bloco correto mas operação retorna bloco defeituoso Erro persistente bloco correto mas operação retorna bloco defeituoso, mesmo depois de sucessivas tentativas Erro não detectado bloco está defeituoso mas operação retorna bloco correto, ou bloco correto mas operação retorna um valor diferente do conteúdo do bloco

Eventos indesejáveis da operação write Escrita nula o bloco não é mudado Escrita incompleta o bloco se torna defeituoso após a escrita

Eventos espontâneos indesejáveis Corrupção o bloco muda de correto para defeituoso Recuperação o bloco muda de defeituoso para correto Erro não detectado o bloco muda de valor

Armazenagem estável usando um único disco Primitivas básicas CarefulRead(e) elimina erros temporários CarefulWrite(e, d) elimina escrita nula e escrita incompleta Dividir disco em pares de blocos informação duplicada independentes em relação a eventos espontâneos pelo menos um dos blocos sempre terá um estado correto O objetivo de um meio de armazenagem estável é prover as operações read(e) e write(e, d) de forma correta, mesmo que falhas possam ocorrer em alguns de seus componentes. Como um número finito de recursos não pode prover tolerância total a faltas, o que estamos atrás de implementar são aproximações de um meio de armazenagem estável. Armazenagem estável pode ser implementada usando-se um único disco, da seguinte forma: primeiro constrói-se uma unidade de disco um pouco mais robusta, que implementa duas operações - CarefulRead(e) e CarefulWrite(e, d). A operação CarefulRead(e) executa uma operação read(e) repetidamente até que ela retorne o estado correto, ou que o bloco não pode ser lido (dois de um número de tentativas). A operação CarefulWrite(e, d) executa um write(e, d) seguido de um read(e) até que a operação read(e) retorne o estado correto e o valor d (isso elimina erros de escrita nula e escrita defeituosa). Para se precaver contra eventos espontâneos e faltas durante a escrita, o disco é dividido em pares de blocos (independentes em relação a eventos espontâneos), e cada par implementa a duplicação de um bloco.

Primitivas de acesso ao disco StableRead(e) faz CarefulRead(e) em um dos pares; se não tiver sucesso, faz CarefulRead(e) no outro par StableWrite(e, d) faz CarefulWrite(e, d) em um dos pares; quando a operação retorna sucesso, faz CarefulWrite(e, d) no outro par Cleanup() faz a consistência do disco após uma falha do nodo (normalmente na inicialização do sistema) Por fim, implementa-se as primitivas de acesso ao disco StableRead(e) e StableWrite(e, d). É preciso implementar também uma primitiva para tratar inconsistências devido a quedas durante a execução de um StableWrite(e, d).

Eventos indesejáveis mascarados erro de leitura temporário e persistente escrita nula e defeituosa corrupção de um bloco Eventos não mascarados erros não detectados quedas do disco ou do nodo A implementação com um único disco mascara os seguintes eventos não desejáveis: erro de leitura temporário, escrita nula, escrita defeituosa, erro de leitura persistente, além de corrupção de um bloco. Ela não mascara erros não detectados. Além disso, quedas do disco ou do nodo não podem ser tratadas.

Armazenagem estável usando replicação Pares de blocos são organizados em discos distintos Discos espelhados Mascaram falhas do disco, controladora ou nodo Boa aproximação de uma unidade de armazenagem estável só não mascara erros não detectados RAID’s Uma outra solução é ter cópias do disco acessíveis através de nodos e controladoras replicadas. Esta solução é uma extensão da solução anterior, onde pares de blocos são organizados em discos distintos, o que normalmente requer algum suporte de hardware. Quando o número de componentes replicados é dois, esta solução é conhecida como espelhamento de discos. Por questões de fiabilidade e de desempenho, discos espelhados devem ter duas portas de acesso e ser conectados a duas controladoras. Além dos erros tratados na solução anterior, discos espelhados também toleram faltas de um disco, controladora ou nodo. Desta forma, eles provêm uma boa aproximação de uma unidade de armazenagem estável.

Mecanismos Básicos: Entrega Confiável de Mensagens
Definição do problema Uma mensagem enviada de i para j é recebida por j corretamente Mensagens enviadas por i são entregues a j na ordem em que foram enviadas Implementação Detecção de erros Ordenação e garantia de entrega Tratamento de falhas

Como fazer comunicação um-para-muitos? Broadcast Multicast Propriedades de interesse Fiabilidade Ordenação consistente Causalidade

Caracterização do sistema Comunicação via troca de mensagens Sistema síncrono (d) Relógios são sincronizados (e) Semântica de falha arbitrária para os nodos Até k nodos e l canais de comunicação podem falhar Não há partições da rede

O objetivo é garantir as seguintes propriedades: terminação: todo valor disseminado por um transmissor correto no tempo t é entregue a todos os nodos corretos no tempo t+D atomicidade: qualquer mensagem disseminada no tempo t ou é entregue por todos os nodos corretos no tempo t+D ou não é entregue a nenhum nodo; ordem: as mensagens entregues são entregues na mesma ordem em todos os nodos corretos

Protocolo de Cristian (protocolo-D) Implementado por três processos Transmissor: inicia a transmissão de mensagens Repetidor: difunde mensagens recebidas Entregador: ordena e entrega mensagens estáveis Mensagens estáveis Para tolerar faltas por omissão: D=kd+Dk,l+e Para tolerar faltas de desempenho ou arbitrárias: D=k(d+e)+Dk,l+e Para redes completamente conectadas: D=(k+1)(d+e)

Outros protocolos Sistemas síncronos Protocolos baseados em temporizadores ao invés de relógios sincronizados Nodos Voltan e Seljuk Sistemas assíncronos (time-related) Ordenação causal Isis, Horus e Ensemble Transis NewTOP

Mecanismos Básicos: Nodos com Semântica de Falha Controlada
Por que restringir a semântica de falhas de componentes? Simplificação de projetos Como se escolhe a semântica de falha de componentes? Qualidade do componente Requisitos da aplicação Tempo de missão

Como implementar nodos com semântica de falha controlada Replicando processadores com semântica de falha menos restritiva Máquina de estados processamento determinístico submeter réplicas às mesmas entradas validar saídas

Nodos com semântica de falha por parada (fail-stop) Propriedades de um nodo fail-stop falha silenciosa armazenagem estável é mantida após a parada do nodo qualquer nodo pode detectar a falha de um nodo fail-stop

Implementação com armazenagem estável Um nodo fail-stop k-resiliente é composto por k+1 processadores convencionais e um nodo confiável implementando armazenagem estável Assinatura digital para autenticar origem Comunicação é feita via armazenagem estável Pedidos de leitura/gravação são enviados por cada processador para o nodo de armazenagem Qualquer diferença entre os valores para o mesmo pedido indicam uma falha do nodo

Implementação sem armazenagem estável Um nodo fail-stop k-resiliente é composto por k+1 processadores convencionais O nodo de armazenagem estável é implementado por 2k+1 processadores convencionais Para escrever na armazenagem estável, um acordo Bizantino é iniciado com o nodo de armazenagem; qualquer diferença nos valores do mesmo pedido indicam uma falha do nodo Para ler faz um broadcast e usa o valor majoritário

Implementação em hardware de um nodo com semântica de falha silenciosa (crash) processador entrada saída comparador processador

Implementação em software PMQ Servidor DMQ Links Links Ordenador Remetente Sim Não Links RMQ deve ser ECL Validador ordenada? ICL VMQ Links Receptor Transmissor Mensagens originadas da rede Mensagens destinadas à rede

Vantagens dos nodos hard Impacto mínimo no desempenho Impacto mínimo no projeto do software Vantagens dos nodos soft Possibilidade de uso de diversidade no projeto Uso de componentes off-the-shelf Facilidade de expansão Maior robustez contra a ocorrência de faltas geradas por uma causa comum

Como proceder? A escolha não é clara, porém ... O tempo de projeto de nodos hard é longo (entre 1 e 2 anos), e enfrenta alguns problemas sérios Para algumas aplicações, o impacto no desempenho introduzido nos nodos soft pode não ser muito grande

Mecanismos Básicos: Replicando Componentes
Estratégias de replicação Replicação ativa modelo da máquina de estados determinismo de réplicas ordenação das entradas grau de replicação sistema k-resiliente semântica de falhas assumida

Estratégias de replicação Replicação passiva primária e cópias pontos de salvaguarda + detecção de falhas mais simples quando não ocorrem falhas réplicas podem ser não-determinísticas recuperação mais lenta só tolera faltas de componentes com semântica de falha silenciosa

Estratégias de replicação Replicação semi-ativa tenta prover as vantagens das outras duas abordagens recuperação rápida tratamento de não-determinismo só tolera faltas de componentes com semântica de falha silenciosa

Sistemas Distribuídos

Apresentações semelhantes

Apresentação em tema: "Sistemas Distribuídos"— Transcrição da apresentação:

Apresentações semelhantes

Sobre projeto

Feedback

Login

Autorizar-se através da rede social:

Sistemas Distribuídos

Apresentações semelhantes

Apresentação em tema: "Sistemas Distribuídos"— Transcrição da apresentação:

Apresentações semelhantes

Sobre projeto

Feedback