UNIVERSIDADE REGIONAL INTEGRADA DO ALTO URUGUAI E DAS MISSES CAMPUS DE ERECHIM DEPARTAMENTO DE ENGENHARIAS E CINCIA DA COMPUTAO CURSO DE CINCIA

DA COMPUTAO

ELVIS ROBERTO FABIANE

TOLERNCIA A FALHAS

ERECHIM - RS 2012

PREFCIO

O aumento do uso dos computadores em quase todos os aspectos da vida moderna levou a necessidade de ter sistemas de computadores altamente confiveis. A tolerncia a falhas um segmento em que a confiabilidade dos sistemas computacionais pode ser aumentada alm do que pode ser atingido por mtodos tradicionais. Sistemas de tolerncia a falhas utilizam redundncia para mascarar os vrios tipos de defeitos. Tolerncia a falhas no uma rea nova. Alguns conceitos de tolerncia a falhas foram propostos pelo prprio Von Neumann. A primeira conferncia na rea IEEEs International Conference on Fault Tolerant Computing Systems (FTCS) iniciou a mais de duas dcadas atrs. Entretanto, o trabalho inicial em tolerncia a falhas foi focado quase exclusivamente em tolerncia falhas suportada em hardware. A rea de aplicativos tolerante a falhas relativamente nova. Tolerncia a falhas geralmente considerada como consistindo de duas subreas: tolerncia a falhas em hardware e tolerncia a falhas em software. Essa diviso no precisamente definida, de modo geral, a tolerncia a falhas em software abrange aqueles mtodos em que a tolerncia a falhas contra diferentes tipos de defeito amplamente suportada em software, enquanto a tolerncia a falhas em hardware onde a tolerncia a falhas suportada amplamente em hardware. Considerando que a atividade de tolerncia a falhas em hardware geralmente vem sob o alcance da comunidade de engenharia eltrica, os tpicos sobre tolerncia a falhas em software so, em grande parte, de interesse para a comunidade de cincia da computao. Este livro uma tentativa de organizar o acervo de conhecimentos na rea de tolerncia a falhas em software. Como a maioria das tcnicas propostas nesta rea usam sistemas distribudos como plataforma bsica, o livro foca na tolerncia a falhas em sistemas distribudos. No entanto, sempre que necessrio (por exemplo, falhas de projeto de software), o caso ser discutido como um caso especial de sistemas distribudos. O livro trata um sistema distribudo tolerante a falhas como consistindo de nveis de abstrao. Os diferentes nveis fornecem diferentes servios tolerantes a falhas. Os nveis mais baixos so as abstraes que so to frequentemente necessrias por tcnicas de tolerncia a falhas do que os nveis mais altos que ns os consideramos como blocos de construo bsicos. H as abstraes de processos fail-stop (implementao que requer protocolos de acordo Bizantino), armazenamento estvel, comunicao confivel, clock sincronizados, e deteco de defeitos. Para suportar servios tolerantes a falhas, um sistema distribudo geralmente suposto a fornecer essas abstraes. O nvel seguinte a abstrao de difuso atmica e confivel, que tambm um alicerce para muitas tcnicas de tolerncia a falhas, mas exige a entrega confivel de mensagens ponto-aponto e abstraes de processos fail-stop para implementao. Abstraes de difuso atmica e segura so teis para suportar os servios tolerantes a falhas em que a comunicao um para muitos necessria. Estes dois nveis mais baixos fornecem "blocos de construo", que por si s so de uso limitado, mas so utilizados para apoiar os servios tolerantes a falhas. Os prximos cinco nveis lidam com os servios tolerantes a falhas. Talvez o mais simples servio de usurio tolerante a falhas est se recuperando de um sistema distribudo para um estado consistente, se ocorrer algum erro. O prximo nvel de atendimento ao usurio tolerante a falhas garantir a atomicidade de aes. Enquanto a recuperao do estado consistente simplesmente garante que um estado consistente do sistema atingido, com aes atmicas h aes definidas pelo usurio ou operaes que precisam ser executadas atomicamente, mesmo se ocorrerem falhas durante a execuo da ao. O foco dos servios destes dois nveis a coerncia cm as falhas. Com aes atmicas, uma ao geralmente anulada se ocorrer uma falha enquanto a ao est em execuo. Evidentemente, o servio tolerante a falhas prxima desejvel tem que assegurar que as aes sejam sempre completas, mesmo se ocorrerem falhas. Para isso, os dados em que as aes ou processos operam deve ser acessvel mesmo se ocorrerem falhas. Estes formam os prximos dois nveis de servios tolerantes a falhas. Mtodos e protocolos in nveis acima discutidos visam fazer algum servio de usurio tolerante a falhas contra ns e falhas de comunicao. Mesmo com estes, um sistema pode falhar

devido presena de falhas de design de software em aplicativo de usurio. Assim, ao mais alto nvel ns consideramos falhas de design de software. Neste nvel, o objetivo fornecer uma abstrao em que o software mascare suas prprias falhas. Os vrios nveis so mostrados na figura P.1.

Figura P.1. Nveis de um sistema distribudo tolerante a falhas

O livro organizado da seguinte forma. Cada nvel de abstrao discutido em um captulo separado. Para cada abstrao, sua precisa definio e motivao dada, junto com um levantamento dos importantes mtodos de apoio a abstrao. O captulo 2 descreve o sistema distribudo geral e suas propriedades. O captulo 3 contm os blocos de construo bsicos, Para cada uma das abstraes discutidas nesse captulo, um ou dois mtodos importantes para apoio a abstrao so descritos. Captulo 4 discute a abstrao de transmisso segura e suas variaes. Protocolos para apoiar os diferentes tipos de transmisso so descritos. Captulo 6 ao 9 discute os servios de tolerncia a falhas. O captulo 5 descreve as duas abordagens para recuperao de um estado consistente e alguns mtodos para fazer isso. Captulo 6 discute como aes podem ser feitas atmicas em um sistema distribudo. Protocolos de recuperao necessrios para isso tambm so discutidos. Data Resiliency discutido no captulo 7. Vrias abordagens para o gerenciamento de replicao de dados para fornecer uma viso de uma cpia so descritos. Captulo 8 discute resilient processes. Mtodos para apoiar a resilincia para diferentes mtodos de comunicao so descritos. Finalmente, o captulo 9 discute os mtodos para fazer um software tolerante a falhas contra seus prprios defeitos de projeto. O caso uniprocess discutido como um caso especial de sistemas distribudos. Embora os sistemas de tolerncia a falhas comercial e experimental construdos no terem sido discutidos separadamente, muitas das tcnicas usadas por esses sistemas tem sido tratadas nos diversos captulos. Este livro pode ser usado com um manual para uma graduao/curso de alto nvel sobre tolerncia a falhas em um departamento de Cincia da Computao, ou por um curso profissional em tolerncia a falhas. Tambm pode ser usado como uma referencia por pesquisadores/ profissionais que trabalham na rea. Pode tambm ser usado como uma referncia ou um co-texto para um curso sobre tolerncia a falhas em um departamento de Engenharia Eltrica, e pode tambm ser usado como uma referncia ou um co-texto em um curso sobre sistemas distribudos.

A rea de tolerncia a falhas muito abrangente. Assim, embora a maioria dos temas importantes foram abordados no livro, alguns temas foram deixados de fora. Alm disso, todos os temas no foram discutidos em grandes detalhes, como alguns tpicos abrangidos no livro tem um grande volume de literatura e um tratamento compreensivo desses tpicos faria o livro volumoso. Ao longo do livro, a nfase foi colocada sobre as tcnicas e algoritmos ao invs de formalismo, pois o foco do livro avaliar as importantes tcnicas para vrias abstraes. H muitas pessoas que me ajudaram a escrever este livro, eu gostaria de expressar minha gratido a todos eles. Alunos em meu curso de tolerncia a falhas. Tanto no Indian Institute of Technology Kanpur quanto na University of Maryland College Park, merecem um agradecimento especial, como a interao com eles influenciou este livro. Eu sou grato a todas as pessoas que responderam minhas perguntas nos e-mails e que facilmente copiavam e enviavam artigos que no eram acessveis para mim. Tambm sou grato aos estudantes e outros que ajudaram na leitura crtica de vrios trechos do livro. Comentrios ou sugestes sobre o livro sero bem-vindas e podem ser enviadas a mim pelo e-mail jalote@iitk.ernet.in. Pankaj Jalote

CAPTULO 1
INTRODUO
O aumento do uso de computadores e o aumento da dependncia sobre eles levaram a necessidade de sistemas de computadores altamente confiveis. H muitas reas onde computadores realizam tarefas de vida crtica. Alguns exemplos disso so sistemas de controle de avies, sistemas de monitoramento de pacientes, orientao de msseis e sistemas de controle, e sistemas de controle de trfego areo. Nestes sistemas, defeitos nos computadores podem levar a catstrofes, talvez com perda de vida humana. H outras reas de aplicao com dependncia crtica dos computadores, onde defeitos podem causar grandes perdas financeiras ou perda de oportunidade. Os principais exemplos disso so bancos e mercado de aes. Est claro que nessas aplicaes, sistemas altamente tolerantes a falhas so necessrios. Est claro tambm que a necessidade por estes sistemas continuaro aumentando. Confiabilidade definida como a credibilidade de um sistema computacional tal que a dependncia do servio que este proporciona pode ser justificada [Lap85, Lap95]. O servio prestado por um sistema o seu comportamento percebido por seus usurios, onde um usurio outro sistema (humano ou fsico) que interage com o sistema computacional [Lap85, Lap95]. Confiabilidade um conceito geral, e dependendo da aplicao, diferentes atributos podem ser enfatizados. Os atributos mais significativos da dependabilidade so confiabilidade, disponibilidade e segurana. Confiabilidade lida com continuidade de servio, disponibilidade com facilidade para uso, segurana com preveno de consequncias catastrficas para o ambiente, e segurana com preveno de acesso no autorizado e/ou manuseio de informaes. O atributo de maior importncia para a tolerncia a falhas a confiabilidade (e em certa medida a disponibilidade). Um defeito no sistema ocorre quando o seu comportamento no consistente com suas especificaes. Defeitos so causados por falhas em componentes do sistema. Quanto maior o nmero de componentes, maiores as chances de existir um componente defeituoso. A pura complexidade e o nmero de componentes que esto presentes em um moderno sistema computacional atual aumentam a probabilidade de um dos componentes serem defeituosos. Uma vez que defeitos so causados por falhas, uma abordagem direta para melhorar a confiabilidade de um sistema tentar evitar a ocorrncia de falhas ou que elas sejam introduzidas no sistema. Esta abordagem chamada de preveno de falhas. A segunda abordagem para

aumentar a confiabilidade a tolerncia a falhas. O objetivo dessa abordagem proporcionar o servio, apesar da presena de falhas no sistema. Supe-se que as tcnicas de preveno de falhas nunca sero capazes de eliminar todas as possveis falhas, e qualquer sistema real possa ter ou desenvolver falhas. Para aumentar a confiabilidade de um sistema alm do que pode ser conseguido atravs de tcnicas de preveno de falhas, os sistemas devem ser concebidos de modo a que possam prestar o servio, apesar de falhas. Na abordagem tradicional de preveno a falhas, a confiabilidade elevada conseguida atravs da eliminao de falhas possveis antes que o sistema seja colocado em uso regular. Um sistema empregando apenas preveno a falhas no tem redundncia, e todos os componentes devem funcionar corretamente, sem falhar, o tempo todo para que o sistema funcione corretamente. Uma vez que todas as possveis falhas no podem ser antecipadas e eliminadas antes da implantao do sistema, para evitar falhas assume-se que falhas no sistema iro ocasionalmente ocorrer. Para isso, mtodos de manuteno manual so concebidas para reparar o sistema quando a falha ocorre. Da as caractersticas fundamentais de um sistema que depende desta abordagem so: (1) ausncia de redundncia no sistema de falhas de mscara (2), os sistemas falham ocasionalmente, quando qualquer um dos componentes falhar, (3) procedimentos de manuteno manual so usados para reparar o sistema quando ocorrem falhas. Para tais sistemas, falha ocasional e reparao manual so tidas como necessrias. A principal consequncia dessas caractersticas que esse sistema est inacessvel quando ele est sendo reparado aps falhas e nenhuma operao pode ser realizada durante este tempo. Em outras palavras, os trabalhos que esto sendo executadas pelo computador iro, periodicamente, serem realizados para o intervalo de reparao. Para aplicaes onde isso aceitvel, sistemas de computador que empregam a preveno falha s ser suficiente. No entanto, existem aplicaes onde esta importante consequncia do uso apenas da preveno de falhas no aceitvel. As principais razes por que isso no pode ser aceitvel so: (1) inaceitabilidade dos atrasos em tempo real causado pelo manual de manuteno (2), a inacessibilidade de sistemas de reparo manual, e (3) os excessivos custos elevados de perda de tempo e manuteno. A primeira razo existir para qualquer sistema com restries de tempo-real. Exemplos destes so aplicaes de controle de processos, sistemas de orientao, controle de trfego areo e fly-by-wire. A segunda razo predominante para os sistemas que tm de ser notripulados (ou ocupado por pessoas que no esto qualificados para a reparao de sistemas de computador) de forma contnua. Um bom exemplo disso a explorao espacial no tripulada. A terceira razo predomina em aplicaes como o cozimento, os sistemas de suporte vida crtico, e sistemas de defesa. Para aliviar muitos dos problemas da abordagem tradicional da preveno de falhas, a tolerncia a falhas pode ser usado. A tolerncia a falhas utiliza redundncia de proteo a falhas de mscara. Ou seja, o sistema contm componentes que no so necessrios, se nenhuma tolerncia a falhas suportada. Estes componentes redundantes so usados para evitar defeitos no sistema no caso de alguns componentes falharem. Essencialmente, a redundncia usada para substituir o manual de manuteno de "reparao e reconfigurao" automatizada, que, por sua vez, aumenta a confiabilidade e disponibilidade do sistema. As duas abordagens - a preveno de falhas e tolerncia a falhas - so de natureza complementar. Empregando a tolerncia a falhas sem usar as tcnicas de preveno de falhas para construir os componentes no faz muito sentido. Para a tolerncia a falhas ser bem sucedida, desejvel que os componentes do sistema sejam individualmente confiveis. Ou seja, tcnicas de preveno de falhas devem ser utilizados para construir os componentes que sero utilizados para a construo do sistema tolerante a falhas. Alm de usar os mtodos de preveno de falhas para fazer componentes de confiana, os mtodos de preveno tambm so necessrios para verificar e validar o sistema tolerante a falhas. Mesmo com alta confiabilidade no se pode usar os componentes de uma maneira imprpria. Assim, os mtodos devem ser utilizados para validar que o sistema tolerante a falhas realmente tolerante, capaz de mascarar os vrios tipos de falhas.

Os mtodos de preveno de falhas focam em metodologias de concepo, teste e validao; considerando que os mtodos tolerantes a falhas nos concentram em como usar os componentes (construda usando mtodos para evitar falhas) de tal forma que as falhas podem ser mascaradas. A teoria e as tcnicas para a construo de sistemas distribudos tolerantes a falhas o tema deste livro.
1.

CONCEITOS BSICOS E DEFINIES

Antes de discutirmos qualquer aspecto de sistemas tolerantes a falhas, temos de definir o que entendemos por um sistema, erro, defeito, falha, e tolerncia a falhas. Estes termos tm sido usados de diversas formas em diferentes contextos, e os termos de falha, defeitos e erros tm sido frequentemente usados como sinnimos. Agora algum consenso sobre as definies desses termos e conceitos que eles representam. Nesta seo, damos definies gerais a estes termos a seguir os conceitos apresentados em [AL81, Rob82, Lap92]. 1.1.1 Modelo de Sistema Primeiro temos que perguntar o que um sistema, a fim de discutir os sistemas tolerantes a falhas. O conceito de sistema bastante geral e existe em outras disciplinas tambm. Mesmo em computao, o conceito bastante geral e representa vrias coisas em contextos diferentes. Assim, uma definio bastante ampla e geral de um sistema necessrio. Ns definimos um sistema como um mecanismo de identificao que mantm um padro de comportamento em uma interface entre o sistema e o seu ambiente. Esta definio implica que o sistema deve interagir com seu meio ambiente, e que um ambiente do sistema necessrio para a definio de um sistema. Essencialmente, a especificao do ambiente define os limites do sistema de interesse. O padro de comportamento na interface ento, o comportamento externo do sistema, o que observado pelo ambiente. O ambiente pode ser dividido em sub-ambientes com cada partio de ter seu prprio padro de comportamento para com o sistema. Esta partio normalmente feito para gerenciar a complexidade de definir o comportamento de um sistema, e chamar a ateno para os sub-interfaces que so de interesse primrio. Ao fazer isso, por exemplo, podemos ignorar, se desejar, a interface de um sistema de computador com o ar em torno dela e seu comportamento na gerao de calor que a interface (embora isso possa ser a sub-interface de interesse para o designer de dissipadores de calor para as placas e chips). Um usurio do sistema pode ser considerado um sub-ambiente, ou a parte ou o meio ambiente, cujo principal objetivo usar o servio prestado pelo sistema. Para isso, ativamente interage com o sistema, fornece insumos para ele, e recebe as sadas do sistema. O usurio pode ser um humano ou outro sistema. Note que a interface do prazo, na definio do sistema, um conceito e no uma entidade. Nos sistemas de computador, muitas vezes, a interface de hardware representa identificveis ou entidades fsicas. Tais entidades, com esta definio do sistema, podem se considerar como um sistema com suas interfaces conceituais. Na definio do sistema, a interface usado apenas para identificar uma fronteira entre o sistema e o seu ambiente. Esta definio do sistema a partir do ponto de vista do seu comportamento externo. Embora seja necessria para identificar o que um sistema seja, ele no oferece nenhum ajuda para especificar a estrutura interna de um sistema. preciso fazer mais para isso. A maioria das disciplinas de engenharia utilizam um sistema / subsistema hierarquia para definir uma estrutura do sistema. Ns seguimos a definio em [AL81, Rob82]. Um sistema considerado como sendo composto por um nmero de componentes ou subsistemas, que interagem sob o controle de um projeto. Cada subsistema um sistema de direito prprio, com o seu prprio comportamento externo e sua prpria estrutura interna. Se um sistema em estudo um dos sistemas a nvel de N, em seguida, cada sistema a nvel N um subsistema de nvel (N+1). Cada sistema no nvel N composto de uma srie de subsistemas nvel (N-1), e cada

sistema a nvel regional (N-1) composto por uma srie de subsistemas nvel (N-2), e assim por adiante. Este sistema / subsistema hierarquia continua at um nvel acima, o que no possvel ou no desejvel para especificar os detalhes do sistema. Subsistemas neste ltimo nvel so chamados de componentes do sistema ou componentes atmicos. O nvel no qual os componentes so considerados atmicos aplicao tpica ou problemas de dependncia. Por exemplo, se estamos interessados no comportamento de cada porta em um sistema de computador (talvez a considerar as falhas ao nvel da porta), ento essa hierarquia continuar, at chegarem aos portes. Por outro lado, se estamos interessados apenas no comportamento dos principais componentes, como memria, CPU, armazenamento secundrio, e uma rede de interligao (como o caso tpico em sistemas distribudos), ento nossa hierarquia no precisa olhar para a estrutura detalhada composta de placas, chips, ou portes. O comportamento externo (ou o estado externo) de um sistema uma abstrao de seu estado interno. O estado interno do sistema compreende os estados externos dos seus componentes. Durante a execuo, o estado interno do sistema passa por uma sequncia de mudanas, determinadas pela interao entre seus componentes. Algumas das mudanas no estado interno so refletidas como mudanas no estado externo do sistema. Para decidir se o comportamento de um sistema correto ou no, temos que ter alguma base de comparao, que narra o comportamento correto do sistema. Tradicionalmente, o comportamento esperado ou correto de um sistema dado por suas especificaes. As especificaes incluem o servio esperado, o que inclui as sadas, bem como as interaes do sistema e as condies sob as quais o servio deve ser prestado. Idealmente, queremos que as especificaes sejam completas, consistentes e corretas. Integralidade implica que o comportamento total do sistema especificado em todas as situaes possveis. Consistncia implica que as especificaes no se contradizem tal que impossvel para um sistema de implement-las .Finalmente, a correo implica que as especificaes especificam o que era "realmente intencionado". Se as especificaes so suspeitos de terem falhas, por si s, ento no podemos dizer se o comportamento de um sistema "incorreto" ou se as especificaes esto com defeito. Em tais situaes, geralmente alguma autoridade externa empregada para se pronunciar. De modo geral, com o processo de arbitragem, podemos supor que as especificaes so autoritrios. Este conceito de especificaes autoritrias tambm pode ser formalizado atravs do conceito de Sistema de Referncia Autorizadas [Rob82], no qual, o autoritrio Sistema de Referncia (ASR) para um sistema simboliza o processo de autoridade que determina se ou no uma interpretao proposta de uma especificao ou a especificao em si, est correto. Ns vamos usar as especificaes termo para se referir s especificaes autoritrias, ou um ASR. 1.1.2 Defeito, Erro, e Falha Para o modelo de sistema acima definido, tendo em conta as especificaes do sistema, a falha de um sistema pode ser definida. Uma falha do sistema ocorre quando desvia primeiro o comportamento do sistema a partir do que exigido por suas especificaes [AL81]. Ou seja, um sistema falha quando no consegue prestar o servio desejado. Um erro a parte do estado do sistema que susceptvel de conduzir a [Lap85, Lap92] falha subsequente. Se houver um erro no estado do sistema, ento existe uma sequncia de aes que podem ser executadas pelo sistema e que levar a uma falha no sistema, salvo algumas medidas corretivas que so empregadas. A causa de um erro uma falha. Como o erro uma propriedade do estado do sistema, ele pode ser observado e avaliado. Falhas, em contrapartida, no so uma propriedade do estado do sistema, e no podem ser facilmente observadas (a menos que os mecanismos especiais so utilizados para registrar a ocorrncia de alguns tipos de eventos). Normalmente, a ocorrncia de uma falha deduzida atravs

da deteco monitorada, e se as formas Estado acompanham a parte do comportamento esperado do sistema, ento se for detectado um erro implica que ocorreu uma falha. Desde defeitos so essencialmente observados para detectar o erro na sada, eles sero detectados se o erro for realmente observado. Por exemplo, se o estado no est sendo monitorado continuamente, mas avaliado em intervalos fixos, ento a falha no pode ser observada. Da mesma forma, uma falha tambm pode passar despercebida se o estado de sada completa no est sendo monitorado e ocorrer um erro em uma parte que no est sendo monitorado. Uma vez que geralmente no possvel avaliar o estado inteiro para determinar um erro, importante que o estado a ser avaliado seja escolhido com cuidado, se queremos pegar a maioria das falhas. Em geral, sempre que algo der errado ns atribumos isso a alguma falha Dizemos que um sistema no est funcionando corretamente devido presena de uma falha. Falha est associada a uma noo de defeito. Um sistema defeituoso o nico com defeitos. Ns definimos a falhas como os defeitos que tm o potencial de gerar erros. Apesar de uma falha ter potencial para gerar erro, ela no pode gerar qualquer erro durante o perodo de observao. Em outras palavras, a presena de culpa no garante que ir ocorrer um erro. O inverso, porm, verdade. Um erro no estado do sistema implica a presena de falhas no sistema. Por exemplo, se uma clula de memria de tal forma que ele sempre retorna o valor 0 independentemente do que esteja armazenada nele, ento ele contm um erro. No entanto, esta falha pode no se manifestar at que a clula de memria com defeito utilizado e um valor de 1 armazenada nele, antes da recuperao. Enquanto a clula de memria com defeito no for usado, ou um valor de 0 armazenado no mesmo, o fato de que a memria contm um erro no vai se manifestar. Falhas podem ser caracterizadas como transitrias ou permanentes. Falhas transitrias so falhas de durao limitada, causada pelo mau funcionamento temporrio do sistema ou devido a alguma interferncia externa. Falhas transitrias podem causar uma falha ou um erro, apenas no perodo em que elas existem. O erro causado por falhas transientes tambm podem existir apenas por um curto perodo. Isso faz com que a deteco de falhas fique muito difcil. Se uma falha transiente raramente ocorre e os danos causados podem ser corrigidos, em seguida, a sua deteco no necessria. No entanto, se a falha intermitente e transitria ocorrendo repetidamente (mas sempre por um curto perodo), ento a sua deteco desejvel. Deteco de falhas bastante difcil e caro. Falhas permanentes so aquelas em que uma vez que o componente falha, ele nunca (ou por um longo perodo de tempo) funciona corretamente novamente. Muitas tcnicas de tolerncia a falhas assumem que os componentes falham permanentemente. Em sistemas distribudos, tambm, ns somos amplamente interessados em falhas permanentes causadas por defeitos permanentes. Falhas tambm podem ser caracterizadas pela fase em que so introduzidas [Lap92]. Falhas de projeto so aquelas que surgem durante o projeto do sistema ou durante a modificao do sistema. Falhas operacionais so aquelas que aparecem durante a vida til do sistema e so causadas devido a razes fsicas. Geralmente, falhas de projeto so muito mais difceis de tolerar que as falhas operacionais. Exceto para o ltimo captulo do livro, que trata de falhas de software de design, o resto do livro trata de falhas operacionais. 1.1.3 Tolerncia a Falhas Por fim, definimos o que se entende por tolerncia a falhas, o tema deste livro. Um sistema tolerante a falhas se pode mascarar a presena de falhas no sistema usando a redundncia. O objetivo de tolerncia a falhas evitar o erro do sistema, mesmo se h presena de falhas. O sistema, como um todo, no pode ser tolerante a falhas contra seus prprios fracassos. Isto , uma vez que ocorreu falha no sistema nada pode ser feito, pois a falha j ocorreu. No entanto, um sistema pode ser feito de tolerncia a falhas contra o fracasso de seus componentes. E esse o objetivo de tolerncia a falhas: para evitar o fracasso do sistema global, quando alguns de seus subsistemas falharem. Em outras palavras, ela mascara a falta de um subsistema de nvel superior.

Um sistema considerado tolerante a falhas se o comportamento do sistema, apesar do fracasso de alguns dos seus componentes, coerente com as suas especificaes. Assim, se algum componente de um sistema defeituoso, ento o sistema tolerante a falhas se a falha do componente (e a presena de falhas no componente) mascarado, ou seja, no se reflete no comportamento externo do sistema. Muitas vezes no necessrio que o comportamento do sistema inteiro seja mantido como est (na verdade, pode ser impossvel, uma vez que o mascaramento da falha do componente pelo uso de redundncia ter algum efeito sobre o comportamento externo, pelo menos no desempenho ), mesmo que alguns dos componentes falharem. Existem alguns servios ou imveis de interesse particular (para o pedido de que o sistema tolerante a falhas est sendo projetado), e so essas propriedades que devem ser preservados, apesar da falha de alguns componentes definidos. Na verdade, como veremos no decorrer do livro, a maioria dos problemas para os quais foram propostas solues pode ser caracterizada pela propriedade ou funcionalidade do sistema a ser preservado, e os tipos de falhas a serem tratadas. O objetivo da maioria das tcnicas especficas propostas o de preservar alguma propriedade desejada sob a face de um conjunto de falhas. Redundncia a chave para apoiar a tolerncia a falhas, pois no pode haver tolerncia a falhas sem redundncia. Redundncia definida como as partes do sistema que no so necessrias para o correto funcionamento do sistema, se nenhuma tolerncia a falhas deve ser apoiada. Ou seja, o sistema funciona corretamente sem redundncia, se no houver falhas. Redundncia em um sistema pode ser de hardware, software, ou tempo. A redundncia de hardware inclui componentes de hardware que so adicionados a sistema de apoio tolerncia a falhas. Redundncia de software inclui todos os programas e instrues que so empregados para apoiar a tolerncia a falhas. Uma tcnica comum para tolerncia a falhas executar alguma instruo (ou sequncia de instrues) muitas vezes. Esta tcnica requer redundncia de tempo, isto , o tempo extra para executar tarefas para tolerncia a falhas. Em sistemas distribudos, com frequncia, todas as trs formas de redundncia so utilizadas. A redundncia de hardware empregada na forma de processadores extras, a memria, ou links de comunicao. Redundncia de software empregada para a gesto destes componentes de hardware extra e us-los corretamente para a prestao de servio continuado, no caso de alguns componentes falharem. O tempo extra tambm geralmente exigido pelos mtodos de tolerncia a falhas em sistemas distribudos. 1.2 FASES NA TOLERNCIA A FALHAS Conforme definido anteriormente, um sistema tolerante a falhas tenta impedir o fracasso do sistema, apesar do fracasso de alguns dos seus componentes. Por natureza, a implementao de tolerncia a falhas em qualquer sistema particular estar intimamente ligada com o sistema e sua arquitetura e design. Assim como projetar um sistema depende das propriedades / requisitos do sistema, projetando um sistema tolerante a falhas tambm uma funo das necessidades e da funcionalidade do sistema. Claramente, nenhuma tcnica geral, pode ser proposta para acrescentar a tolerncia a falhas em um sistema. No entanto, alguns princpios gerais que so teis na concepo de sistemas tolerantes a falhas podem ser identificados. Aqui vamos especificar algumas atividades que em geral a maioria dos sistemas que empregam tolerncia a falhas tem a desempenhar. Ao fornecer tolerncia a falhas, quatro fases podem ser identificadas: a deteco de erros, confinamento de danos, recuperao de erros, e tratamento de falhas e sistema de servio de forma contnua [AL81]. A deteco de erros a fase em que a presena de uma falha deduzida atravs da deteco de um erro no estado de alguns subsistemas. Uma vez que um erro foi detectado, isso implica que a falha do componente ocorreu. Qualquer dano causado devido falha deve ser identificado e delimitado na segunda fase do confinamento. Muitas vezes, o projeto do sistema tem de incorporar mecanismos para ajudar a limitar a propagao de erros no sistema, assim, limitando os danos aos limites pr-determinados. Estas duas fases so realmente as fases de deteco, que so

necessrios para iniciar as atividades para tolerar a falha. Depois destes, o erro no estado tem que ser corrigido. Isso feito na fase de recuperao de erro. Desde que haja um erro no estado do sistema, necessrio remover o erro de tal forma que ele no faa com que se propague para aes futuras. Com a recuperao de erro, o sistema vai atingir um estado livre de erros. At agora, as atividades esto centradas em torno de erro no estado do sistema. Na fase final de tratamento de falhas e sistema de servio continuado, a culpa ou o componente defeituoso tem de ser identificado, e o sistema tolerante a falhas tem a funo tal que os componentes defeituosos no so utilizados ou utilizados de uma forma diferente ou de configurao, que a falha no volte a causar defeitos. Estas so as quatro atividades gerais que so geralmente executados em qualquer sistema de apoio a tolerncia a falhas. Em algumas situaes, algumas dessas fases podem ser feitas implicitamente ou podem ser simples, mas a sequncia geral das atividades a especificada por estas fases. No restante desta seo, vamos discutir estas etapas em detalhes. 1.2.1 Deteco de erros O ponto de partida de qualquer atividade de tolerncia a falhas a deteco de erro. Conforme discutido no exemplo acima, falhas e erros no podem ser diretamente observados, mas tm de ser deduzidos a partir da presena de erros. Como o erro definido pelo estado de um sistema (ou subsistema), os checks podem ser realizados para ver se h um erro ou no. A partir da presena de erros, defeitos e as falhas podem ser deduzidas. Assim, os mecanismos de deteco de erros so muitas vezes referidos como " deteco de defeitos / falhas", e na presena de um erro na sada de um componente declarado como falha do componente. A eficcia de um regime de tolerncia a falhas depender claramente da eficcia do mecanismo de deteco de erros utilizada. No entanto, tais mecanismos exaustivos para deteco de erros muitas vezes no so praticveis. Devido importncia da deteco de erros, vamos primeiro determinar o que uma seleo ideal para a deteco de erros. H algumas propriedades importantes que uma verificao de deteco de erro deve satisfazer [AL81]. Primeiro, uma seleo ideal deve ser determinada unicamente a partir das especificaes do sistema e no deve ser influenciada pelo design interno do sistema. Qualquer influncia do sistema sobre a seleo pode causar o mesmo erro na deteco de erros, o sistema deve ser tratado como uma "caixa preta". Em segundo lugar, uma seleo ideal deve ser completa e correta. Isto implica que deve ser capaz de detectar todos os possveis erros no comportamento do sistema que podem ocorrer a partir da presena dessas falhas que o sistema tolerante a falhas visa segurar, e que nunca declara um erro quando no h erros presentes . Com uma verificao completa e correta, pode-se afirmar que, se nenhum erro foi detectado, ento no h falhas (de interesse) no sistema, e se for detectado um erro, um erro (e, portanto, uma falha) est presente no sistema. Claramente, se a checagem no est completa, alguns erros podem passar despercebidos, o que mais tarde causa um defeito no sistema. Em terceiro lugar, a verificao deve ser independente do sistema com relao suscetibilidade de falhas. Se tivermos um cheque que tambm falha quando o sistema falhar, ento o cheque de nenhum valor prtico. Gostaramos de uma seleo para que um modo de falha independente, isto , ele falha independentemente do sistema. Se isso for satisfeito, a probabilidade de que a seleo vai falhar, ao mesmo tempo que o sistema seja minimizado. Em sistemas reais, estes critrios raramente so totalmente satisfeitos. Apenas aproximaes so possveis. Normalmente, no possvel executar uma verificao completa sobre o estado de sada, uma vez que essa verificao pode ser muito complexa e, portanto, mais chances de estar com defeito. Alm disso, uma verificao completa pode impor restries financeiras e de desempenho que so impraticveis. Da mesma forma, verificaes prticas no so susceptveis de serem executadas em todas as sadas possveis em todos os momentos possveis, para colocar essa verificao, as informaes sobre a estrutura do sistema frequentemente utilizado. Essas informaes so normalmente utilizados para garantir uma maior "cobertura". Finalmente, mesmo a independncia do cheque a partir do sistema no pode ser plenamente obtido, uma vez que, finalmente, a verificao e o sistema devem compartilhar algum ambiente (alimentao, mesma

caixa, mesma sala, etc.) e nada de errado com o meio ambiente, ento, causar tanto a falhar (por exemplo, se h radiao que faz com que todo o hardware para executar de forma incorreta, uma seleo baseada em hardware tambm falhar junto com o sistema de hardware). Tendo em vista as limitaes prticas, os controles para a aceitao so frequentemente utilizados para deteco de erros, em vez de cheques ideais. Uma checagem aceita no uma checagem ideal, mas uma aproximao. O objetivo dos controles de aceitao manter o custo do controle de deteco de erro baixa, e ao mesmo tempo maximizar os erros que forem detectados. Estes controles no garantem que no h erros detectados, mas tentar capturar a maioria dos erros de interesse, especialmente os que so mais provveis de ocorrer. Os controles de deteco de erros que so empregados em sistemas de computador podem ser de diferentes tipos, dependendo do sistema e as falhas de seu interesse. No entanto, existem alguns tipos gerais de cheques que so mais frequentemente empregados. Vamos agora discutir brevemente estes [AL81]. Replicao de Checks. Replicao de Checks so um dos controles mais comum e poderosos. Replicao de checks podem ser bastante completo e pode ser implementado sem o conhecimento da estrutura interna do sistema a ser replicados. Como o nome sugere, essa verificao de replicao envolve alguns componentes do sistema. Os resultados dos componentes diferentes so comparados, ou votados, para detectar erros. Devido a isto, tambm um dos mais caros mtodos de deteco de erros. O tipo e a quantidade de replicao depende da aplicao. Pode-se supor que o projeto do sistema est correto e as falhas ocorrem devido a causas fsicas, e as falhas dos componentes so independentes, um componente pode ser replicados muitas vezes. Esta forma de replicao utilizada frequentemente em hardware. Redundncia Modular Tripla (TMR), que discutido mais adiante neste captulo, usa esse mtodo. Replicao usando cpias idnticas de um componente funciona se o projeto do componente est correto. Tais replicaes de verificao claramente no funcionam se o projeto do sistema pode estar com defeito. Para a manipulao de design de falhas, a replicao pode ser usada, mas os componentes de replicao devem ser diferente no design tambm. Ou seja, todos os componentes replicados implementam as especificaes do componente, mas de forma independente. Se os defeitos causados por erro no projeto so independentes, tolerncia a falhas contra defeitos de projeto podem ser alcanados. Vamos discutir isso mais tarde, no contexto de falhas de software. A replicao tambm usada em sistemas para outros fins que no a deteco de erros. Por exemplo, em sistemas distribudos, a replicao amplamente utilizada, embora no com a finalidade de deteco de erro. Normalmente, os dados ou processos so replicados em um sistema distribudo em diferentes processadores de tal forma que o fracasso de alguns componentes do sistema distribudo pode ser tratado. A deteco de falhas normalmente feita por cheques de tempo (Discutido a seguir). A replicao utilizada em grande parte de servio continuado e isolamento de falhas. Verificao de tempo. Se as especificaes de um componente incluem restries de tempo, os cheques de tempo podem ser usados para verificar se essas restries so respeitadas ou no. Verificao de tempo normalmente definem um temporizador com um valor determinado a partir das especificaes do componente. Se o timer "expira", isso significa que a restrio de tempo do componente violada. Uma violao de programao, muitas vezes implica que o componente se comporta de forma incorreta e suas outras sadas tambm podem ser um erro. Assim, indiretamente, um "erro de timing" tambm significa um erro no estado do sistema. Verificaes de tempo so frequentemente utilizadas tanto em sistemas de hardware e software para detector situaes problema. Os conjuntos de temporizadores para detectar problemas de sincronismo so por vezes tambm chamado de watchodog timers. A maioria dos hardwares do sistema utilizam controles de tempo para detectar problemas no acesso memria ou

acesso na bus. Em software, sistemas operacionais, por exemplo, os temporizadores so utilizados extensivamente para a deteco de situaes que podem levar a mais problemas. Em sistemas distribudos, erro de timing desempenha um papel central. Uma das falhas dos componentes mais comuns que as tcnicas de tolerncia a falhas tenta mascarar a "falhas de ns". Um n um componente em um sistema distribudo. O sistema distribudo frequentemente especifica uma restrio de tempo que um n de trabalho deve responder dentro de algum tempo definido. Esse tempo geralmente calculado com base nos atrasos envolvidos na rede de comunicao. Se um n no responder dentro do tempo limite, seu comportamento declarado errado e o n assumido como tendo falhado. Esta a forma mais comum de verificao para detectar a falha de ns. Verificaes Estruturais e de Codificao. Em qualquer dado, dois tipos gerais de controle so possveis: verificao semntica e verificao estrutural. Verificao Semntica tenta assegurar que o valor consistente com o resto do sistema. Verificaes estruturais consideram apenas os dados e garantir que, internamente, a estrutura dos dados como deveria ser. Se a redundncia construda para a representao dos dados em si, ento a verificao estrutural pode ser utilizada para identificar dados errados. A forma mais comum de verificao estrutural, amplamente utilizado em hardware, a codificao. Na codificao, os bits extras so adicionados aos bits de dados, de tal forma que o valor desses bits extra sempre relacionado com o valor dos bits de dados. Os mecanismos de controle so baseados na verificao de codificao dessa relao. Se os bits de codificao ou os bits de dados esto corrompidos, essa relao violada, e o erro detectado. Vamos continuar a discutir a codificao mais adiante neste captulo. Verificaes estruturais, embora mais amplamente utilizadas em hardware, podem tambm ser empregadas em sistemas de software. Em sistemas de software, verificao estrutural pode ser concebida para estruturas de dados, especialmente se houver alguma redundncia nas estruturas de dados. As estruturas de dados que usam a redundncia, a fim de facilitar os controles estruturais so chamadas de estruturas de dados robusta [TMB80a, TMB80b]. Nas estruturas de dados robusta, se as estruturas de dados corrompida, em seguida, usando a redundncia e verificaes estruturais, possvel detectar e at mesmo corrigir a parte danificada das estruturas de dados. No entanto, desde o caso de corrupo na estrutura de dados muito frequente, em comparao com a corrupo de dados em nveis mais baixos no hardware, estruturas robustas de dados tm um uso limitado, mas muito mais se o hardware subjacente for muito confivel. Verificao de Razoabilidade. Verificao de Razoabilidade determina se o estado de algum objeto no sistema "razovel". Um exemplo comum a verificao da razoabilidade gama, onde determinado que um determinado valor est dentro de um intervalo especificado. Estes testes de razoabilidade no garantem que o valor est correto, s que o valor est dentro de uma faixa (que inclui o valor correto tambm). Dado que os cheques no podem ser criados para a correo do valor, so utilizados intervalos. O intervalo de valores aceitveis determinado a partir da aplicao. Outra variao deste acompanhar a taxa de mudana de algum valor, a taxa de mudana deve ser dentro de alguns limites. Este formulrio pode ser de uso particular em sistemas de controle, onde a mudana de valores tem de ser contnua e, portanto, a taxa de variao de parmetros torna-se limitada. Uma das formas mais comuns de verificao de intervalo que frequentemente utilizado o tempo de execuo de verificao de escala realizada pelo sistema. Muitas linguagens, como Pascal, usam as declaraes de estruturas de dados (e os limites de suas dimenses) dado pelo usurio para gerar automaticamente a verificao de intervalo de tempo de execuo. Se o valor est fora do alcance, ou se a verificao de intervalo falha durante a execuo, a execuo do programa abortado e sinais necessrios so gerados. Estas verificaes so gerados automaticamente a partir da redundncia que est incorporada nos programas Pascal na forma de dados explcitos e declaraes do tipo.

Outra verificao de razoabilidade possvel sobre as afirmaes sobre o estado do sistema. Uma assero uma expresso lgica sobre o valor das diferentes variveis, do sistema, que ir avaliar para true se o estado do sistema consistente, caso contrrio ela ir avaliar para false. Afirmaes so por vezes utilizados na deteco de erro no software. Diagnstico de cheques. Em diagnsticos de cheques, um sistema emprega algumas verificaes sobre o seu componente para ver se o componente est funcionando corretamente. Diferentemente de outras formas de controle, onde a seleo faz parte do sistema para detectar um erro em seu estado, aqui a verificao feita pelo sistema no seu componente. Diagnsticos de cheques so geralmente os valores de entrada especiais para os quais so conhecidos os valores corretos para o sistema de uso anterior. Para cada um dos valores de entrada a sada comparada com o valor correto armazenado para determinar se existe um erro. Verificaes de diagnsticos so frequentemente usadas em sistemas no momento em que ele esta sendo ligado. Neste contexto, so normalmente chamadas de "auto-verificaes. Verificao de diagnsticos geralmente exige que o sistema pare de executar as operaes do usurio. Essa restrio faz com que seja seu uso seja limitado em muitos ambientes, no entanto, como mencionado acima, usado com frequncia para a verificao inicial do sistema quando ele est sendo ligado. Neste momento, j que no h usurios no sistema, uma verificao de diagnstico vivel.

1.2.2 Confinamento e Avaliao de Dados Ao detectar um estado de erro no sistema, sabemos que em algum lugar do sistema existem falhas. No entanto pode haver um atraso de tempo entre o erro e o evento de deteco. Esse atraso pode ocorrer porque o sistema no est a ser continuamente monitorados para os erros. Devido interao entre os componentes durante esse atraso, um erro pode se propagar para outras partes do sistema. Assim, no momento em que for detectado um erro na sada de um componente, o erro pode ter se espalhado para outras partes do sistema. Portanto, aps a deteco de um erro, antes que o estado incorreto do sistema pode ser corrigido, preciso determinar exatamente os limites da corrupo, ou partes que esto corrompidas. Este o objetivo desta fase. Os erros do sistema se propagam atravs da comunicao entre os componentes do sistema. Assim, para avaliar a quantidade de danos no sistema, aps ter sido detectado o erro, o fluxo de informaes entre os diferentes componentes do sistema tem que ser examinado. Algum pressuposto tem de ser feitos sobre a origem do erro, ou quando o erro foi originado. Ento, todo o fluxo de informaes aps o erro pode poderia propag-lo para outras partes. O objetivo identificar os lugares por onde essas informaes passaram. O dano , ento, limitado a esses lugares. O limite pode ser identificado dinamicamente pelo registo e anlise do fluxo de informaes. No entanto, este mtodo poder ser complexo. A melhor maneira criar um sistema onde "fire walls" sejam incorporados estaticamente ao sistema. Estes fire walls garantem que o fluxo de informaes fique somente dentro desses fire walls. Se for detectado um erro dentro desta rea definida estaticamente, ento h uma grande probabilidade de que o erro no se espalhou para alm dos fire walls (a menos que a falha tinha ocorrido antes da computao ter entrada na rea dos firewalls). Na maioria dos sistemas, a estrutura esttica usada para assumir a propagao dos danos. Muitas vezes a atividade de avaliao de danos no realizada de forma explcita, e a estrutura do sistema usada na fase posterior de recuperao de erro para decidir a quantidade de recuperao, indiretamente fazendo suposies sobre o confinamento dos danos.

1.2.3 Recuperao de Erros Uma vez que o erro foi detectado e identificado, hora de remover o erro. A menos que o erro seja removido, o estado errado pode causar uma falha no futuro. Nesta fase de recuperao, o sistema esta livre de erros. Esta uma das mais importantes atividades e tem sido enfatizado em muitos trabalhos anteriores sobre tolerncia a falhas. De fato, em alguns sistemas, a recuperao apropriada de erros uma meta aceitvel, isto , todos esses sistemas querem que, em caso de ocorrerem falhas, o sistema deve ser restaurado para um estado consistente. Existem duas tcnicas para recuperao de erros em geral: backward recovery e forward recovery. Na backward recovery o estado do sistema restaurado para um estado anterior, na esperana de que o estado anterior seja isento de erros. Este mtodo requer que o estado do sistema seja verificado e salvo (checkpointed) periodicamente em algum armazenamento estvel que no seja afetado pela falha. Quando algum erro ou falha detectado, o sistema revertido para o ltimo ponto de verificao (checkpointed). Se a falha ocorreu aps o checkpoint ser estabelecido, o ponto de verificao ser livre de erros e depois desta reverso, o sistema tambm ser livre de erros. Backward recovery uma das formas mais usadas de recuperao de erros. bastante geral, e no depende muito da natureza da falha ou erro. Ele pode se recuperar de falhas arbitrrias, seja transitria ou permanente. Na verdade, muito apropriado em caso de falha transitria, porque depois da recuperao nada mais precisa ser feito. O problema causador da falha j ter acontecido, e reiniciar o sistema a partir de um ponto salvo no ir produzir erro novamente. A principal desvantagem deste tipo de recuperao a sobrecarga necessria. Primeiro, o ponto de verificao tem de ser feito com frequncia no armazenamento estvel. Isso afeta a execuo normal do sistema, mesmo que no falha. Depois, h um processo de reverso envolvidos em caso de falha, o que faz com que haja algum desperdcio de computao no sistema. Apesar da sobrecarga, devido ao seu carter geral e da simplicidade, ela usada com frequncia. Na forward recovery, nenhum estado anterior est disponvel, e o sistema no volta para um estado anterior. Em vez disso, a tentativa a de "ir para a frente"e tentar tornar o sistema livre de erros, tomando as devidas aes corretivas. Na teoria, o conceito interessante, pois provvel que seja eficiente em termos de sobrecarga. No entanto, pela prpria natureza de recuperao para a frente, ser necessrio fazer uma avaliao do dano causado ao sistema, e sobre a natureza do dano, ou erro. S se a natureza do erro for conhecida, que o erro poder ser removido por aes corretivas. Assim, um bom diagnstico da razo e dos danos ao sistema dever ser feito. Isso faz com que a forward recovery de um sistema seja uma abordagem dependente do aplicativo. Devido a isso, no usado como to comumente quanto a backward recovery. Em sistemas distribudos, por exemplo, a backwars recovery empregada na maioria dos casos. 1.2.4 Tratamento de Falhas e de servio Continuado Nas trs primeiras fases, o foco est no erro. Primeiro, o erro detectado, o prejuzos so avaliados e s depois removidos. Depois disso, temos o sistema em um estado livre de erros. Isso pode ser suficiente se o erro foi causado por alguma falha transitria. Aps a recuperao de erro, o sistema pode ser reiniciado (a partir de um estado livre de erros), e nenhum erro ocorrer, pois a falha no existe mais. No entanto, se as falhas so permanentes, o que causou a falha e o erro ainda permanece no sistema, mesmo aps a recuperao de erros. Se reiniciar o sistema aps a recuperao de erros, ento o mesmo problema far com que as mesmas falhas e erros ocorram novamente. Para evitar isso, essencial que os componentes defeituosos sejam identificados e no mais utilizados na computao aps a recuperao. Isto , de alguma forma o componente defeituoso tem de ser "ignorado", sem comprometer a computao. Este o objetivo desta fase. Esta fase tem duas sub-fases importantes: localizao do defeito e reparo do sistema. Na localizao do defeito, o componente que contm a falha tem de ser identificado. A menos que o

componente defeituoso j seja conhecido e nenhum mecanismo pode ser empregado para reparar a falha ou assegurar-se que o componente defeituoso no causar uma falha novamente. Normalmente, aps a deteco de erros e avaliao, o componente defeituoso identificado como o componente que contm a fonte do erro. Na reparao do sistema, o sistema "consertado" de tal forma que o componente defeituoso no seja mais utilizado. Um ponto importante a ser observado que esse reparo on-line e feito sem interveno manual para que seja considerado um sistema tolerante a falhas. Se o reparo manual utilizado, ento no um sistema tolerante a falhas. Este reparo feito por um sistema de reconfigurao dinmico, de tal forma que a redundncia, que est presente no sistema usado para executar a tarefa do componente falho. Uma das mais simples estratgias para a reparao do sistema a estratgia de reposio em espera. Neste, h um componente redundante de espera no sistema. Se o componente principal falhar, o componente que esta em modo de espera utilizado e o componente defeituoso ignorado. Uma vez que o sistema fora reparado, o servio normal pode continuar, como se nada tivesse acontecido. Devido a isso, em geral, o efeito de tolerncia a falhas , no mximo, um pouco de descontinuidade no servio ou alguma degradao de desempenho. Mas o sistema no ficara indisponvel para os servios do usurio. Em sistemas distribudos, por falhas de nodos de processamento, a deteco de um nodo defeituoso pode ser feito com base na auto deteco de falhas. Como os nodos so tratados como uma entidade completa e, normalmente, um n defeituoso no pode fazer outro nodo se comportar incorretamente (ou seja, a possibilidade de um erro ser propagado remoto), e a deteco de falhas identifica o n com defeito. O reparo do sistema feito usando outros ns do sistema para realizar a tarefa do n que falhou. 1.3 PANORAMA DA TOLERNCIA DE FALHA DE HARDWARE A tolerncia a falhas pode ser, e aplicada a nveis diferentes em um sistema de computador. Podemos tratar um sistema de computador como um sistema de camadas, com o mais alto nvel de aplicaes e portas (ou at mesmo em uma unidade menor) at no nvel mais baixo. As camadas mais baixas deste modelo sero consideradas como o "hardware", enquanto as camadas superiores sero consideradas como "software do sistema (software)". difcil definir o que constitui a tolerncia a falhas de hardware e o que constitui tolerncia a falhas de software. Intuitivamente, ns vamos considerar todas as tcnicas que visam proporcionar tolerncia a falhas de hardware, que visam mascarar componentes falhos, como os mtodos de tolerncia a falhas de hardware. O objetivo deste livro de se concentrar nos princpios e tcnicas de tolerncia a falhas nos nveis de sistemas de software, onde a tolerncia a falhas suportado em grande parte do software. Por uma questo de completude, apresentamos uma breve descrio das tcnicas de tolerncia a falhas de hardware nesta seo. Esta uma rea vasta e livros completos podem ser escritos em alguns dos temas sobre a tolerncia a falhas de hardware. Nosso objetivo aqui apenas familiarizar o leitor com o que a tolerncia a falhas de hardware e quais as tcnicas bsicas. Para mais detalhes, o leitor poder consultar [Lal85, Joh89]. 1.3.1 Processo de Desenvolvimento de Hardware O hardware moderno passa por diversas fases durante o seu desenvolvimento. Primeiro, vamos dar uma viso geral de um processo tpico de desenvolvimento de hardware [AA86]. Inicialmente, muitos circuitos integrados (CIs) so fabricados em uma nica pastilha de silcio. Esses CIs so chamados matrizes nesta fase. Os testes so realizados nesta fase para detectar matrizes defeituosas, que so ento marcadas. A pastilha de silcio ento cortada em matrizes individuais, e as marcadas so descartadas. O percentual de pastilhas que no esto com defeito chamado de rendimento de produo. O percentual de matrizes que no esto com defeito

chamado o rendimento do processo de fabricao. Para a integrao em larga escala (LSI) e a integrao em escala muito grande (VLSI), o rendimento frequentemente muito baixo (50% ou menos). Isto se deve complexidade destes circuitos e do grande nmero de portas que esto presentes em um CI. A preciso exigida enorme, mesmo uma partcula de poeira em uma matriz causar uma falha no teste. As matrizes que passam o teste so encapsuladas para o IC, as trilas entre os componentes so feitas e os pinos so fixados sobre as matrizes. Isto novamente uma atividade de alta preciso. O chip encapsulado ento testado. Este um teste importante, que exige muitas vezes complicados sistemas de alta velocidade. O equipamento de teste normalmente carregado com uma sequncia de entradas e as sadas corretas que so esperadas do CI para as entradas. O equipamento de teste processa estes casos de teste em altssima velocidade. Para aplicaes de alta confiabilidade, os chips podem ser "queimados em altas temperaturas para acelerar as falhas e, em seguida testados novamente. Os chips que falham no teste so descartados. Os chips so os montados em placas de circuito impresso (PCB), e ento essas placas so testadas. Aqui tambm tipicamente so feitos testes de entrada e sada, onde um equipamento especializado empregado. Sondas so muitas vezes colocados em vrios pontos do circuito para obter as sadas intermediarias. Os PCBs so colocados juntos para formar um sistema. O sistema testado antes de ser enviado. Esta montagem do PCB em um sistema pode ser feito em fases, a primeira formao do subsistema e, em seguida, formando o sistema completo. Os testes aqui podem exigir a execuo do sistema de uma maneira semelhante ao seu uso esperado. Quando o sistema passa no teste, ele ser enviado para o uso dos clientes. 1.3.2 Falhas e Modelos de Erros Ao contrrio do software, que no tem propriedades fsicas e, portanto, nenhuma causa fsica de falha, falhas de hardware tm sua origem em causas fsicas. Falhas de hardware podem ser de fabricao ou que ocorrem com o passar do tempo. Os dois no so independentes, e problemas na produo podem ter efeito sobre as falhas dependentes do tempo. As falhas fsicas que ocorrem durante a fabricao incluem dispositivos com defeito, quebra de ligaes, curtos entre as linhas, as impurezas das embalagens que afetam o funcionamento do chip. As falhas que ocorrem com o passar do tempo incluem quebras, curtos, e mudana na tenso de alimentao. A maioria das falhas fsicas so curtos e aberturas de linhas. Apesar de que as falhas fsicas so as causas bsicas das falhas de um chip, na maioria dos casos, no nos interessa a falha fsica em nvel micro que faz com que alguma pea de hardware fique com mau funcionamento. S estamos interessados em saber se a falha est presente ou no, ou seja, estamos interessados nas consequncias de uma falha fsica. Um mtodo de fazer isso descrever o efeito das falhas fsicas em algum nvel superior. Este maior nvel pode ser no nvel de portas e circuitos lgicos, em nvel de bloco funcional, no nvel do chip, etc. Um modelo abstrato denominado modelo de falhas. Um modelo de falha especifica o efeito das falhas fsicas. A esperana que algumas falhas no modelo de falha podero descrever com preciso a maioria das falhas fsicas. Se isso puder ser feito, para apoiar a tolerncia a falhas, apenas falhas do modelo necessitaro ser consideradas. Normalmente, muitas falhas a nvel fsico podem ser modeladas pela mesma falha em um nvel mais alto. O modelo de falhas pode ser definido em um nvel muito alto (digamos, um nvel de placa ou subsistema) ou um nvel baixo (nvel de transistor). Se formos para um nvel muito baixo, ento o modelo de falha ir conter as falhas fsicas em si, e se formos a um nvel muito alto o modelo de falhas pode no ser capaz de cobrir todas as falhas dos nveis inferiores. Aqui iremos descrever alguns dos mais comuns modelos de falhas. Modelos de Falha em nvel de portas logicas. Modelos de falha em nvel de portas logicas so muito frequentes na tolerncia de falhas de hardware. O modelo clssico deste nvel uma porta logica travada em 1 ou 0. Com isso, este modelo capta a falhas e quebras de ligao do circuito, que so as falhas mais comuns em CIs pequenos. Outro modelo de falhas, que um subconjunto

travamento das portas, o modelo de falhas por pinos. Neste, apenas os pinos dos chips so considerados presos, em 0 ou 1. A generalizao desses modelos o de mltiplas falhas , onde vrias linhas esto presos em algum valor. Um modelo relacionado, embora frequentemente caracterizado como um modelo de erro, o modelo de erro unidirecional. Nesse sentido, em um conjunto de linhas em que todos os 0s tornam-se 1s, ou em todos os 1s tornam-se 0s. Esses casos geralmente ocorrem quando algumas linhas entram em curto com outras. Apesar de o modelo-preso refletir com preciso as deficincias fsicas em CIs de pequeno porte, em CIs grande, feitos a partir da tecnologia MOS, algumas das falhas fsicas no podem ser modeladas. Uma quebra em uma linha de um transistor CMOS muitas vezes faz com que o CI se comporte como se tivesse memria, e a falha s poder ser detectada se a sada da porta CMOS inicializada corretamente. Isso faz com que at mesmo um circuito combinacional se comporte como um circuito sequencial. O modelo que capta esta propriedade de memria em caso de cortes chamado o modelo de falhas aberto. Por outro lado, os defeitos causados por um transistor que conduz permanentemente so modelados pelo modelo-preso. Com a densidade crescente de circuitos integrados, curtos entre linhas adjacentes se tornaram bastante comuns. Tais defeitos so modelados pelo modelo de falhas de ligao. Outro modelo de falhas que considerado importante o modelo de falhas por atraso. Este, por sua vez, modela a degradao por atraso em uma porta ou em um caminho no circuito. Tal degradao pode causar um valor lgico incorreto no travamento da sada. Modelos de falha em nvel de funes. Esses modelos refletem as deficincias fsicas com bastante preciso. No entanto, eles so muito detalhados pelo fato de se ter que considerar a estrutura do nvel de portas de um circuito. Para fornecer tolerncia a falhas, j que mais provvel que um chip com defeito ser descartado, muitas vezes mais importante saber simplesmente se um chip est ou no funcionando. O modelo de falhas no nvel funcional tenta modelar falhas do nvel de mdulos funcionais. claramente desejvel que o modelo de falha inclua os efeitos da maior parte das falhas fsicas ou em nvel de portas lgicas. Um modelo de falhas muito geral para blocos funcionais assumir que uma funo N entradas, em falhas, pode ser transformada em outra funo, com N entradas. Tal modelo de falhas no caracteriza o total comportamento, e , portanto, de uso limitado para tolerncia a falhas. No parece haver nenhum modelo de falha geral no nvel de bloco funcional. No entanto, os modelos de especficos, mdulos funcionais tm sido propostos. Por exemplo, em um decodificador de N entradas e 2N sadas, normalmente linha ativada correspondendo ao endereo de entrada. Tem sido demonstrado que todas as falhas nos nveis mais baixos de um decodificador podem ser descritas por um conjunto de trs falhas [AF86]. Estas falhas so (1) uma linha incorreta ativada, (2) mais de uma linha ativada, e (3) nenhuma linha ativada. Da mesma forma, os modelos tm sido propostos para multiplexador [AF86], e outros pequenos mdulos funcionais. Modelos de falhas funcionais tambm esto usados, extensivamente para testes de redes lgicas, em que a clula defeituosa altera a sua funo de forma arbitrria. Modelos de falha de memria. A memria principal (Random Access Memory, memria RAM) no sistema de um computador , conceitualmente, um conjunto de clulas de memria. Para ter acesso, a memria principal tambm deve conter um decodificador de endereos, leitura / escrita, lgica e registradores de dados para transferncia de dados. Um conjunto amplamente usado de modelo de falhas funcionais para a memria contm as seguintes falhas: (1) uma ou mais clulas so presos em 0 / 1, (2) algumas clulas so acoplados e quando uma clula altera o seu valor, outras clulas acopladas tambm mudam os seus valores, e (3) estado de uma alterao de memria celular como resultado de algum estado das clulas de memria. Agora vamos discutir algumas das tcnicas mais comuns que esto sendo usadas, para suporte a tolerncia a falhas no hardware. Esta tambm uma rea muito vasta em que h progresso constante. Nosso objetivo no dar uma imagem completa ou um tutorial de todas as tcnicas, mas apresentar alguns das mais conhecidas. Para mais detalhes, o leitor pode consultar [La185, SW82]. 1.3.3 Redundncia Modular Tripla (TMR). - Fim Ricardo

A mais conhecida tcnica de tolerncia a falhas para hardware a redundncia modular tripla (TMR), que tem sido utilizado em sistemas tolerantes a falhas. O conceito foi originalmente sugerido por Von Neumann. Na TMR, a unidade de hardware (representado por M na fig. 1.1) triplicada, e todas as trs unidades trabalham em paralelo. As sadas destas trs unidades so dadas ao eleitor (representada por V na fig. 1.1). O eleitor admite como correta a sada fonte mais votada.

Figura 1.1: redundncia modular tripla Claramente, a organizao TMR pode completamente mascarar o fracasso de uma unidade de hardware. Um dos recursos mais interessantes do TMR que nenhuma ao explcita precisa ser realizada para deteco de erros, recuperao, etc TMR particularmente adequado para falhas transitrias, uma vez que em um TMR bsico, o eleitor no remove o componente com defeito depois que um erro ocorre. Tambm evidente que este regime no pode lidar com o fracasso de duas unidades. De fato, uma vez que uma unidade falhar essencial que ambas as unidades devem continuar a funcionar corretamente (para que o eleitor possa obter uma maioria). Devido a isso, a confiabilidade do sistema TMR torna-se menor do que um sistema simples (ou seja, um sem redundncia) quando ocorre uma falha (veremos esse ponto mais adiante neste captulo). No entanto, do ponto de vista prtico, dupla falha tambm pode ser tratada com a TMR em muitos casos. Por exemplo, se oeleitor votar bit a bit e as duas unidades apresentarem respostas erradas em bits de diferentes posies, a falha dupla pode ser mascarada. Do mesmo modo, se duas unidades esto com defeito, de modo que uma linha de sada de uma unidade fica presa em 0, e na mesma sada da outra unidade, ela fica presa em 1, ento a falha dupla tambm pode ser manipulada. Em outras palavras, h situaes em que os erros vo "compensar" ao natural, ou em separado. Nessas situaes, a falta de unidades tambm pode ser tratada por TMR. O esquema TMR depende criticamente o elemento de voto. No entanto, o elemento de voto normalmente um circuito simples e o circuito mais confivel dessa complexidade que pode ser construdo. Outro aspecto na implementao da TMR que ele requer sincronizao perfeita entre as diferentes unidades. Isto tem sido frequentemente feito usando um nico clock. Isso requer que o relgio seja muito confivel. Uma generalizao da abordagem TMR a abordagem de RMN, no qual a unidade replicada N vezes. 1.3.4 Redundncia Dinmica. Um sistema com redundncia dinmica consiste em diversas unidades, mas com apenas uma operando por vez [Lal85]. As outras unidades so essencialmente reservas. Se uma falha detectada na unidade em operao, ento ela desligada e uma unidade de reposio ligada por um circuito de comutao. Um dos principais problemas desta abordagem como detectar se uma unidade falhou. As abordagens comuns para a deteco de falha em uma unidade so:
1.

Testes peridicos

2. 3.

Circuitos de alto-verificao Watchdog timers

Esquemas de redundncia dinmica podem ser classificados como sistema cold-standby ou sistema hot-standby, dependendo da forma como suas unidades reservas so mantidas. Em um sistema cold-standby, uma unidade est ligada e operacional, enquanto as unidades reservas no permanecem ligadas (ou seja, elas esto frias). Uma unidade defeituosa trocada desligando-a e ligando uma unidade reserva. Em um sistema hot-standby, todas as unidades operam simultaneamente e seus resultados so comparados. Se os resultados so os mesmos, um escolhido arbitrariamente. Caso contrrio, a unidade defeituosa detectada e o sistema reconfigurado, de modo que o resultado do sistema saia de uma das unidades que esto operando normalmente. (Uma diferena fundamental desta abordagem da TMR a maneira pela qual a unidade defeituosa detectada e removida.). A forma mais comum para um sistema hot-standby operar duas unidades em paralelo. Isso chamado de um sistema duplex [Lal85]. Um circuito comparador compara continuamente os resultados dos dois. Se uma incompatibilidade ocorre, programas de diagnstico so executados para localizar a falha. Na localizao da falha, a reconfigurao realizada atravs de circuitos de comutao. 1.3.5 Codificao Codificao uma das tcnicas mais importantes para a tolerncia a falhas em hardware. Ela tambm utilizada extensivamente para melhorar a confiabilidade da comunicao. Codificao tem sido usada em muitos sistemas. A ideia bsica por trs da codificao a de adicionar bits de verificao nos bits de informao, tais que os erros em alguns bits possam ser detectados e, se possvel, corrigidos. O processo de adio de bits de verificao aos bits de informao chamado de codificao. Ou seja, a informao codificada por adio de bits de verificao. O processo inverso de extrair informaes a partir dos dados codificados chamado de decodificao. Por isso, a codificao essencialmente fornece verificaes estruturais, em que o erro detectado, detectando inconsistncia na integridade estrutural dos dados. Codificao tambm uma rea onde uma grande quantidade de trabalho tem sido feito [RF89]. Aqui ns damos uma breve introduo a codificao e alguns cdigos comuns de usurio em tolerncia a falhas de hardware. Detectabilidade/Correctabilidade de um Cdigo Um cdigo define um conjunto de palavras que so possveis para aquele cdigo. Ou seja, para um esquema de codificao, existe um conjunto vlido de palavras que satisfazem aquele esquema. A distncia Hamming de um cdigo o nmero mnimo de posies de bits em que quaisquer duas palavras do cdigo diferem. Se d a distncia Hamming, D o nmero de erros de bits que o cdigo pode detectar, e C o nmero de erros de bits que ele pode corrigir, a seguinte relao sempre verdadeira. d = C + D + 1, com D > C. No cdigo binrio regular, a distncia Hamming 1 (o cdigo de dois nmeros consecutivos geralmente difere em um bit), e assim a sua detectabilidade e correctabilidade so ambos 0. O mtodo comum de adicionar um bit de paridade para uma palavra aumenta a distncia Hamming para 2 (se a palavra binria difere de uma posio, ento o bit de paridade tambm ser diferente, criando uma distncia de 2). Com d=2, podemos apenas detector erros de um nico bit (ou seja, D=1). Valores maiores de D ou C no satisfazem a relao acima. Esta relao especifica a limitao fundamental de um determinado cdigo.

Cdigos de Hamming A adio de um bit de paridade, apesar de ser um mtodo comum, s pode detector erros em 1 bit. Um mtodo mais geral usado cdigos de Hamming em que vrios bits de paridade so adicionados de modo que cada bit de paridade a paridade de um subconjunto de bits de informao. O cdigo pode tambm detectar e corrigir erros. amplamente utilizado em memrias de semicondutores. Nos cdigos de Hamming, os bits de paridade ocupam as posies de bits 1, 2, 4, ... (potncia de 2) na codificao. As restantes so as posies dos dados. Se nos referirmos ao nmero de bits de paridade por k, e o nmero de bits de dados por m, para m=4 e k=3, o comprimento da palavra codificada de 4+3=7 bits. Destes 7 bits, os bits em posies 1, 2 e 4 so os bits de paridade e bits em posies 3, 5, 6, 7 so os bits de dados, como mostrado abaixo. Os bits de paridade so rotulados c1, c2 e c3, e os bits de dados so marcados como d1, d2, d3 e d4.

O valor dos bits de paridade definido pelas seguintes relaes:

Um bit de paridade (ou um bit de verificao) o OU-Exclusivo de um subconjunto de bits de dados. interessante notar como essas relaes so obtidas. Para c1, que o bit de paridade na posio 1, todos os bits de dados, cuja posio na palavra codificada, quando representada em binrio, tem o bit menos significativo (LSB) como 1, esto includos no c1. Da mesma forma, todos os bits de dados cuja representao binria contm um 1 na segunda posio ser includa no c2. Assim, c1 inclui bits de dados 1, 3 e 4, j que elas ocorrem em posies 3, 5 e 7 na palavra codificada, e a codificao binria desses nmeros contm um 1 no LSB (estes so os nmeros mpares). O bit de dados d3 no est includo, uma vez que ocorre na posio 6, cujo binrio de codificao tem um 0 no LSB. Da mesma forma, para c2, bit de dados d1, d3 e d4 so tomados, uma vez que eles ocorrem em posies 3, 6 e 7, e a codificao binria desses tem um 1 no prximo LSB. Esse cdigo de Hamming capaz de detector e corrigir erros em apenas um bit. A distncia de Hamming do cdigo de 3. Ao adicionar mais um bit de paridade, que contm a paridade da palavra do cdigo de Hamming, pode-se obter um cdigo com uma distncia de Hamming de 4. Esses cdigos podem detectar erros duplos e corrigir erros nicos. Muitos chips comerciais de memrias semicondutoras empregam esses cdigos. A deteco de bits errados pode ser feita da seguinte forma. A partir da palavra de cdigo recebida, obter o valor de bits de seleo, usando a relao dada acima. Se os bits de verificao obtidos coincidem com os bits de verificao que existem na palavra codificada, no h erro. Caso contrrio, existe um erro na palavra codificada; ou os bits de dados ou os bits de verificao esto corrompidos. Para corrigir um erro de um nico bit, necessrio determinar a localizao do bit errado. Isso feito da seguinte forma. Os bits de seleo obtidos a partir da relao acima so realizadas operaes de OU-Exclusivo com os bits de seleo obtidos a partir do cdigo. A partir da, temos a localizao dos bits errados. Para o exemplo acima, teremos trs bits: e1, e2 e e3. Se no houver nenhum erro, ento os bits sero 0. Se houver um erro, ento os bits de localizao de erro iro localizar o bit no erro. A correo feita simplesmente complementando o bit. No exemplo acima, se o bit 3 est errado (ou seja, os dados bit d1), ento teremos e1=1, e2=1 e e3=0. A partir da, ns obtemos o endereo do bit incorreto como 011 (ou seja, o terceiro bit). Este sistema de correo de erros funciona, desde que h um nico erro, e pode at mesmo corrigir erros em bits de seleo. O uso de cdigo de Hamming se torna mais eficiente, em termos de nmero de bits necessrios em relao ao nmero de bits de dados, medida que aumenta o tamanho da palavra. Por exemplo, se o comprimento da palavra de dados de 8 bits, o nmero de bits de seleo ser de

4, e assim a sobrecarga ser de 50%. Por outro lado, se o comprimento da palavra de 84 bits, o nmero de bits de verificao ser de 7, dando uma sobrecarga de 9%. Redundncia Cclica de Cdigos (CRC) Estes cdigos so aplicados a um bloco de dados, ao invs de palavras independentes. Os CRCs so comumente usados na deteco de erros na comunicao de dados. Eles tambm so chamados de cdigos polinomiais. Nesse cdigo, uma sequencia de bits representado como um polinmio; Se o k bit 1, ento o polinmio contm xk. Por exemplo, o polinmio para a sequencia de bits 1100101101 x9 + x8 + x5 + x3 + x2 + 1. H um gerador de polinmio G(x) de grau k. Por exemplo o polinmio gerador poderia ser x4 + x3 + 1, correspondente sequencia de bits 11001. A codificao feita da seguinte forma. Para a sequencia de bits de dados, adicione (k+1) bits no final. Essa sequencia de dados estendida dividida (modulo 2) pelo polinmio gerador. Seja qual for o resto adicionado ao final da sequencia de dados estendida para formar os dados codificados (esta adio realmente substitui os bits (k+1) adicionados aos bits de dados). A decodificao fcil se no h erros; Os (k+1) bits extras so apenas descartados para obter os bits de dados originais. Para verificar se h um erro, os bits de dados so novamente divididos pelo polinmio gerador, e o restante final verificado com os ltimos (k+1) bits de dados obtidos. Se houver diferena, um erro ocorreu. CRCs podem detectar todos os erros em um nico bit, mas no podem corrigir erros. Eles tambm podem detectar todos os erros de estouro de comprimento inferior a k. Um erro de estouro onde bits consecutivos so corrompidos. Muitos outros erros tambm tem uma elevada probabilidade de serem detectados. Apenas os erros que so divisveis por G(x) sero detectados. Cdigos Berger Nesse cdigo, o nmero de 0s so contados na palavra de dados, e a contagem anexada como bits de verificao para formar o cdigo. Se o tamanho da palavra k bits, este esquema de codificao exige log2(k) bits extras. Cdigos de Berger podem detectar todos os erros unidirecionais, incluindo aqueles que corrompem bits de verificao. Em um erro unidirecional, todos os bits no erro mudam de 1 para 0, ou de 0 para 1. Se o erro da forma 1 para 0, ento o nmero de 0s nos bits de dados vai aumentar, mas a contagem (cujos bits tambm podem mudar de 1 para 0) ir diminuir. Assim, uma discrepncia ocorrer. Da mesma forma, se os bits mudarem de 0 para 1, o nmero de 0s ir diminuir, mas a contagem vai aumentar. Cdigos Berger so conhecidos por serem timos para a deteco de erros unidirecionais entre todos os cdigos em que os bits de informao e de verificao podem ser separados. Um cdigo de Berger alternativo pode ser obtido pela contagem de nmero de 1s na palavra de dados anexando o seu bit como complemento de bits de verificao. 1.3.6 Circuitos auto verificadores Ns discutimos uma variedade de tcnicas de codificao acima. Todas as tcnicas de codificao trabalham atravs da produo de um cdigo, digamos, de comprimento n, tal que as palavras vlidas (que so consistentes com o mtodo de codificao) so um subconjunto das possveis palavras de comprimento n. Ou seja, das 2 possveis palavras, apenas um subconjunto delas so consideradas vlidas. A redefinio representa a situao em que algum erro tenha ocorrido. O erro detectado verificando se a palavra vlida ou no. Esta redundncia essencial para que um sistema de codificao funcione. Se todas as palavras possveis fossem vlidas, ento um erro poderia converter uma palavra vlida em outra palavra vlida e, portanto, passar despercebida.

A deteco de erros com um esquema de codificao exige que um circuito verificador seja empregado para detectar se uma palavra vlida ou no. Se um circuito funcional produz uma sada codificada y, que ser verificadora para a presena de um erro pelo verificador, ento, a situao pode ser representada como mostrado na figura 1.2 [Toh86]. A verificadora da sada verifica se a sada do circuito funcional vlida ou no, conforme o esquema de codificao utilizado. Se y no uma palavra codificada vlida, ento a sada do verificador de z ser 1, indicando um erro.

Figura 1.2: Verificador de sada O esquema acima para a codificao pressupe que o verificador de erros est funcionando corretamente, de tal forma que mesmo que o circuito funcional no funcione corretamente, o verificador ir detectar o erro. Se houver uma falha no circuito verificador, ento o esquema de codificao pode deixar de fornecer a capacidade de deteco do erro. possvel que o verificador falho que se no tiver erro na entrada do verificador, ele no declare um erro, mas se tiver um erro, ele no o captura. Ou seja, alguns erros podem passar despercebidos, devido presena de falhas no circuito verificador. claramente desejvel ter a capacidade de verificar a ocorrncia de uma falha no verificador, para alm da capacidade de verificar o erro na entrada para o verificador. Este o objetivo dos circuitos de auto verificao. Ns daremos algumas definies para especificar formalmente o que se entende por circuitos de auto verificao [Cs68, Am73, Lal85]. Seja F o conjunto de falhas para que o circuito deve ser de auto verificao. Um circuito seguro a falhas no que diz respeito a um conjunto de falhas F, se por qualquer falha no F, o circuito nunca produz uma palavra de cdigo incorreto na sada para qualquer cdigo de palavra na entrada. Um circuito auto examinador a respeito de um conjunto de F falhas, que por qualquer falha em F, o circuito produz ao menos uma palavra-cdigo a partir de uma palavra de cdigo de entrada. Um circuito totalmente auto verificador no que diz respeito a um conjunto de F falhas se e somente se ele seguro a falhas e auto examinador a respeito a F. Um circuito dito ser possvel ser separado se para cada palavra-cdigo de entrada (nopalavra cdigo) produz uma palavra-cdigo de sada (no-palavra cdigo). Um circuito totalmente auto verificador se e somente se ele for auto examinador, seguro a falhas e for possvel ser separado. Com um verificador auto verificado, possvel detector uma falha no circuito funcional ou no verificador. No entanto, em geral, no possvel dizer qual defeituoso. Como exemplo, considere um verificador auto verificado de paridade [Toh86]. Suponha que (x8, , x0) representa uma palavra cdigo para o esquema de paridade mpar. Divida o conjunto de variveis em dois grupos, por exemplo, os bits de nmero par e os bits de nmero mpar e conecte-os rvore de portas XOR, conforme mostrado na figura 1.3 [Toh86]. Na operao normal, o nmero de 1s em um grupo mpar, e o outro grupo par. Portanto, a sada Z = (z2, z1) ter (0,1) ou (1,0), mas nunca (0,0) ou (1,1). Pode ser visto que, se alguma porta est defeituosa, ento uma das duas sadas ser diferente, resultando em Z sendo (0,0) ou (1,1).

No existem tcnicas gerais para a concepo de verificadores auto verificados. Mtodos especficos foram propostos para os diferentes tipos de cdigos. No entanto, existem algumas tcnicas para a sntese geral de auto verificao dos circuitos combinacionais e sequenciais [JW91]. 1.3.7 Tolerncia a falhas em Multiprocessadores Um sistema multiprocessado aquele que consiste de mltiplos processadores conectados por alguma rede de interconexo. Os processadores normalmente trabalham em conjunto para resolver um problema simples, e geralmente so fortemente acoplados, em contraste com sistemas distribudos onde os diferentes processadores so amplamente independentes. Os processadores se comunicam entre si atravs de mensagens que passam atravs da rede de interconexo. A motivao bsica para multiprocessadores a necessidade de computao de alto desempenho. Recentes avanos na tecnologia VLSI permitem a construo de sistemas multiprocessados mais baratos. Uma vez que existem mais componentes em um sistema multiprocessado que pode falhar, h um grande interesse na rea de tolerncia a falhas de hardware para sistemas multiprocessados. Um sistema multiprocessado considerado tolerante a falhas se, apesar da falha de um ou mais processadores, um nmero de processadores ativos permanecem conectados de acordo com a topologia original para que foram concebidos. Existem vrias abordagens para apoiar a tolerncia a falhas em multiprocessadores. Uma delas a abordagem TMR, que temos discutido acima. Aqui vamos discutir brevemente algumas dessas abordagens. Uma nova abordagem para a tolerncia a falhas em sistemas multiprocessados a tolerncia a falhas baseada em algoritmo, em que a tolerncia a falhas conseguida mediante a adaptao do esquema de tolerncia a falhas para o algoritmo que ser realizado no multiprocessador [HA84. B+90]. Nesta abordagem, os dados so codificados em um alto nvel (ao contrrio de byte/nvel da palavra, como se faz com frequncia). O algoritmo a ser realizado em seguida, redesenhado para trabalhar com dados codificados para produzir uma sada codificada. Finalmente, as etapas de clculo deste algoritmo modificado so distribudas entre os processadores no multiprocessador de tal forma que a falha de um mdulo afeta apenas uma parte dos dados, que podem ser recriados pela redundncia presente nos dados codificados. Como exemplo dessa abordagem, considere operaes de matriz [HA84]. Para uma matriz A, a coluna de soma de verificao da matriz Ac aquela que obtida a partir da matriz original, acrescentando uma linha de soma de verificao. Na linha de verificao, cada elemento a soma dos elementos dessa coluna em particular. Da mesma forma, uma linha da soma da matriz Ar pode ser definida. A matriz da soma total Cf aquela que tem uma linha extra e uma coluna extra, que so a linha e a coluna da soma de verificao. Com essa codificao, se a operao de matriz C = A * B deve ser realizada, ento pode ser facilmente visto que Cf = Ac * Br. Ou seja, o algoritmo de multiplicao de matrizes tem de ser redesenhado para trabalhar em Ac e Br. Da mesma forma, temos Cf = Af + Bf. Relaes semelhantes podem ser definidas para as operaes de transposio e outras tambm. Agora, a matriz de dados foi codificada e o algoritmo de matriz foi redesenhado. A deteco de erros feita de uma forma simples. Calcule a soma de verificao para os elementos de informao na matriz final, e depois compar-lo com a linha de soma de verificao e coluna produzida pelo algoritmo redesenhado. A interseo de linhas inconsistentes e elementos da coluna iro localizar o erro. O erro pode ser corrigido.

Figura 1.3: Verificao automtica de paridade Outra abordagem para tolerncia a falhas em multiprocessadores empregar redundncia dinamicamente [Agr88]. Um processador assumido para produzir o resultado de clculo e uma assinatura. A assinatura um bom representante de resultado do processador e pode ser obtido atravs de tcnicas de compresso de dados. A abordagem a seguinte. Suponha que os processadores so numerados. Inicialmente, uma tarefa de entrada est prevista para um par de processadores, por exemplo P1 e P2. Estes produzem resultados R1 e R2 e assinaturas S1 e S2. As duas assinaturas so comparadas e, se corresponderem, ento um dos resultados retornado. Se as assinaturas no coincidirem, ento o trabalho agendado em outro processador, digamos P3. A assinatura S3 com as assinaturas anteriores S1 e S2. Se um par de assinaturas correspondentes for encontrado, ento o resultado R3 retornado. Caso contrrio, o trabalho agendado em outro processador, at que um par correspondente de assinaturas encontrado. Estas so as abordagens para tolerncia a falhas projetadas especificamente para algumas arquiteturas comuns. Aqui, discutiremos brevemente os mtodos para arquiteturas de rvore e hipercubo. Um multiprocessador hipercubo consiste de 2n processadores que esto conectados por links diretos de acordo com o n-cubo binrio de interconexo padro [Pra86]. Assim, cada processador est diretamente ligado a n outros processadores, e a distncia mxima entre os nodos (em termos de nmero de saltos o ligaes entre si) apenas log(n). Em uma tcnica, dois processadores de reposio so utilizados para todos os oito processadores. Cada nodo assumido que possui n + 2 portas. Ao adicionar estes processadores extras, a dimenso do hipercubo aumentada em um. Quando a falha de um processador normal detectada, ele substitudo por um processador de reposio (por exemplo S), e as ligaes entre o processador de reposio para o processador com defeito e o link diagonalmente a ele, so desativados. S envia seu endereo e o endereo do processador falhado para todos os processadores de reposio conectados a ele. Esta informao ento usada para redefinir as conectividades para que a estrutura de hipercubo seja mantida. Para multiprocessadores organizados hierarquicamente, as redes de rvore oferecem uma rede de interconexo natural. Mas, uma desvantagem inerente dessas redes que uma s falha pode desligar a rede. Diferentes abordagens tm sido propostas para fazer tal rede tolerante a falhas [Pra86]. Uma abordagem aumentar a rvore com ns e links extras. O objetivo preservar a estrutura da rvore original, apesar das falhas, reconfigurando as rvores usando ns e links extras. 1.4 Confiabilidade e Disponibilidade

O objetivo bsico de tolerncia a falhas aumentar a confiabilidade de um dado sistema. Ao empregar a tolerncia a falhas, muitas falhas potenciais so evitadas, aumentando a confiabilidade. Outro objetivo de tolerncia a falhas aumentar a disponibilidade do sistema, ou seja, aumentar o tempo para que o sistema esteja disponvel para o utilizador de servios (em oposio execuo de tarefas de contabilidade interna). Ao menos que uma estratgia de tolerncia a falhas pode aumentar a confiabilidade ou a disponibilidade de um sistema, ela no de interesse. Uma quantidade considervel de trabalho tem sido feita na avaliao de desempenho de sistemas tolerantes a falhas, ou seja, avaliar a confiabilidade, disponibilidade, ou alguma outra medida de desempenho de sistemas que empregam tolerncia a falhas. Est alm do escopo deste livro fazer uma anlise do desempenho dos diversos esquemas de tolerncia a falhas. No entanto, importante entender os dois conceitos-chave confiabilidade e disponibilidade que so as foras motrizes por trs de tolerncia a falhas. Nesta seo, daremos uma breve descrio destes conceitos com base em [Tri82]. Para mais informaes o leitor pode se referir a [Tri82]. Durante o curso do livro, sempre que possvel, vamos discutir isso para alguns dos esquemas propostos. 1.4.1 Preliminares A maioria dos trabalhos realizados na avaliao de desempenho de sistemas de computador tem fundamentos na teoria da probabilidade. A teoria das probabilidades til em situaes onde o resultado de uma experincia no certa. Tal experincia chamada de um experimento aleatrio. Um exemplo clssico de aleatoriedade o lance de uma moeda. Um experimento aleatrio pode ser atirar a moeda n vezes. A totalidade de todos os possveis resultados de um experimento aleatrio chamada de espao amostral do experimento. Por exemplo, para o experimento de jogar a moeda duas vezes, h quatro resultados possveis: HH, HT, TH, TT (onde T representa a ocorrncia de coroa e H representa a ocorrncia de cara). Um evento um subconjunto do espao amostral. Um evento mais frequentemente especificado pelas condies que definem o subconjunto para este evento. Como exemplo, considere o evento pelo menos uma coroa ocorre. Trs dos quarto pontos no espao amostral sero includos neste evento. A probabilidade de um evento representa o risco relativo que a realizao da experincia vai resultar na ocorrncia do evento. A probabilidade de um evento e referido como P(e). Vamos agora dar algumas definies com base em [Tri82]. Definio. Uma varivel aleatria X, em um espao amostral S, uma funo que atribui um nmero real X(s) para cada ponto amostral s S. Estamos mais interessados em variveis aleatrias contnuas, em que cada nmero real x, o conjunto { x | X(s) x} um evento. Variveis aleatrias contnuas so o ponto de partida na maioria dos modelos de confiabilidade. Por exemplo, na modelagem de confiabilidade, o tempo de vida de um sistema ou o tempo de reparao de um sistema so frequentemente modelados como variveis aleatrias. Variveis aleatrias podem ser discretas tambm. No entanto, na modelagem de confiabilidade, na maior parte, variveis aleatrias contnuas so empregadas. Definio. A funo de distribuio FX de uma varivel aleatria X definida como sendo a funo: FX(x) = P(X x), - < x < . A funo de distribuio muitas vezes chamada de funo de distribuio cumulativa, ou CDF. O subscrito X de F mostra que esta a funo de distribuio da varivel aleatria X. Quando fora do contexto, o ndice ser omitido. Ao contrrio de uma funo de distribuio de uma varivel aleatria discreta, a funo de distribuio de uma varivel aleatria continua (que o que estamos tratando) uma funo contnua para todos os valores de x. H algumas coisas a serem observadas sobre a funo de distribuio: (1) Como F(x) uma probabilidade, seu valor est entre 0 e 1, (2) F(x) uma funo monotonicamente no-decrescente; ou seja, se x1 x2, ento F(x1) F(x2), e (3) F(x) tende para 0 quando x .

Definio. Para uma varivel aleatria contnua X, f(x) = d(F(x))/dx chamada de funo de densidade de probabilidade (probability denity function) (pdf) de X. A seguir a definio para um pdf: O CDF pode ser obtido a partir do pdf, integrando-a:

A funo de distribuio, ou a funo de densidade, caracteriza o comportamento de uma varivel aleatria, e as probabilidades de vrios eventos podem ser determinados a partir deste. Frequentemente, ns no precisamos de caracterizao detalhada e que so interessadas apenas na mdia, ou a expectativa de uma varivel aleatria X, que denotada por E[X]. Isso reflete o valor esperado da varivel aleatria X. Definio. A expectativa, E[X], de uma varivel aleatria X definido por:

Desde que a integral seja absolutamente convergente, ou seja: As expectativas tambm so comumente usados em evoluo de confiabilidade. Um mtodo para caracterizar a confiabilidade de um sistema para especificar o tempo mdio de falha, que a expectativa da vida til do sistema (uma varivel aleatria). 1.4.2. A distribuio exponencial Agora estamos prontos para discutir uma distribuio especfica, chamada de distribuio exponencial, que muito frequente na avaliao da confiabilidade de sistemas de computador. Na avaliao de sistemas de computador, muitas vezes, coisas como o tempo de chegada entre dois processos sucessivos em um sistema de computador, o tempo gasto em um processador ou dispositivo de E/S, tempo at a falha de um componente ou sistema, o tempo necessrio para reparar uma falha de componente ou sistema etc, so modelados como variveis aleatrias em distribuio exponencial. A funo de distribuio exponencial dada por:

A funo de distribuio mostrada na fig. 1.4 [tri82]. Se uma varivel aleatria X distribuda exponencialmente, em seguida, a pdf dada por:

Figura 1.4: O CDF de uma varivel aleatria exponencialmente distribuda com parmetro = 1.

Figura 1.5: O pdf de uma varivel aleatria exponencialmente distribuda.

Enquanto especificando o pdf normalmente apenas a parte diferente de zero indicado. O pdf de uma varivel aleatria exponencialmente distribuda mostrado figura 1.5 [tri82]. A distribuio exponencial muito popular na anlise analtica porque ela possui a propriedade memoryless ou Markov. O que significa a propriedade memoryless que se determinou a distribuio de uma varivel exponencialmente distribudos depois de algum tempo t decorrido, a distribuio mais exponencial. Por exemplo, suponha que X representa a vida de um sistema, que exponencialmente distribudo. Suponha que o sistema ainda est vivo depois de um tempo t, ento o tempo de vida residual do sistema tambm ter a funo de distribuio mesmo. Seja Y = X - t representa o tempo de vida residual. Deixe a probabilidade condicional de Y <= y, dado que X> t, ser indicado por Gt (y). Gt (y) uma probabilidade condicional:

Esta expresso, finalmente, torna-se [Tri82]:

Assim, Gt (y) idntica distribuio original dos X, e independente de t. Em outras palavras, se X representa o tempo de vida de um sistema, ento a distribuio do tempo de vida restante do sistema a qualquer tempo t tem a mesma distribuio que o tempo de vida original. Ou seja, o sistema "esquece" o tempo que ele foi ativo, ou no mantm a histria. Esta a propriedade memoryless da distribuio exponencial. frequentemente simplifica a anlise analtica.

1.4.3 Confiabilidade Deixa a varivel aleatria x representa a vida de um sistema. Ou seja, x representa o tempo at a falha do sistema. O tempo at a falha modelado como uma varivel aleatria, pois no pode ser previsto com certeza. Suponha que a varivel x tem distribuio F. a confiabilidade do sistema uma funo R (t), que representa a probabilidade de que o sistema sobrevive at o tempo t (ie, ele no falhou at t).

R(t) = probabilidade de que o sistema esteja funcionando no tempo t = P(X > t) = 1 F(t)
Como podemos ver, a definio implica que R (t = 0) = 1, significando que o sistema est trabalhando inicialmente. Tem tambm R (t = oo) = 0, implicando que nenhum componente tem uma vida til infinita. Se a vida til de um sistema exponencialmente distribuda, ento a confiabilidade desse sistema : O parmetro chamado de taxa de falha do sistema. Essa noo de confiabilidade representa a confiabilidade como uma funo do tempo. A partir disso podemos calcular o tempo mdio para falha (MTTF), ou expectativa de vida, do sistema. MTTF uma medida comumente utilizada para indicar a confiabilidade de um sistema, e dada por:

A partir da expresso temos:

Se a vida til do sistema exponencialmente distribudo com parmetro , ento R(t) = e-t, e temos a expectativa de vida, ou MTTF, do sistema como:

Em anlise mais confivel, a vida de um sistema, ou componente, assumido como sendo exponencialmente distribudo, e ao longo deste livro, salvo indicao em contrrio, vamos usar essa suposio. A expresso acima d o MTTF de um sistema nico, trabalhando de forma isolada. Muitas vezes, um sistema pode ser considerado como uma combinao de muitos componentes independentes, cada uma tendo um tem uma vida distribuda exponencialmente. Vamos considerar um sistema em srie, onde diferentes componentes so ligados em srie para formar o sistema completo. Suponha que a vida til do ith componente na srie exponencialmente distribudo com parmetro i. desde um sistema em srie falhar se qualquer um dos componentes da srie falhar, a confiabilidade do sistema global dada por [Tri82]

Quando a vida de cada componente exponencialmente distribuda, ento esta avaliada como um sistema com uma vida exponencialmente distribudos com parmetro definido da forma:

Portanto, o MTTF do sistema em srie :

Este diz que o MTTF de um sistema em srie menor do que MTTF de qualquer dos seus componentes. Isso de se esperar, uma vez que a falha de qualquer componente causa a falha do sistema em srie, e, portanto, o sistema tem uma srie de confiabilidade mais baixos do que seus componentes individuais. Um sistema pode ser um sistema paralelo em que os componentes do sistema so ligados em paralelo. Nesta organizao, o sistema falha quando todos os componentes falharem. Se X a vida do sistema e Xi representa a vida de um componente i, temos:

Xmax = {X1, X2 ...., Xn}

Isto implica que a confiabilidade de um sistema paralelo maior que a confiabilidade de seus componentes. Com o pressuposto exponencial, o MTTF do sistema passa a ser [Tri82]

Outra organizao de um sistema, que frequentemente usado em tolerncia a falhas, a redundncia de espera. Nesse sentido, um componente (muitas vezes chamado de primrio) opera, e outros agem como espera. Quando o primrio falhar, o componente de espera ligado e comea a operao. Nesta configurao, se X o tempo de vida do sistema, e Xi a vida do componente:

Com distribuio exponencial temos o MTTF do sistema como:

Da o ganho de confiabilidade depende do nmero de componentes. Com 2 componentes com vidas exponencialmente distribudos, a vida do sistema primrio de espera o dobro de um componente individual. Vimos que em hardware, TMR um mtodo amplamente utilizado para apoiar a tolerncia a falhas. Em TMR, trs sistemas esto conectados em paralelo, e suas sadas so escolhidas. O Sistema TMR pode mascarar a falha de um componente. Se R (t) a confiabilidade do componente triplamente replicados, ento, considerando as diferentes combinaes de falhas em que um sistema TMR continua a funcionar, temos [Tri82]:

RTMR(t) = 3R2(t) 2R3(t)

Com a distribuio exponencial RTMR (t) = 3e-2t - 2e-3t. A funo RTMR nem sempre maior do que a funo R(t) = e-t, que sobre a confiabilidade do componente individual. Para valores menores de t, RTMR maior do que R, e para valores maiores de t o contrrio. Podemos calcular t0, o "limite" de tempo para alm do qual a confiabilidade da TMR inferior ao de seus componentes, em t0 temos:

3e-2t - 2e-3t = e-t0.

Resolvendo isso, temos t0 = ln2/ = 0.7/. Portanto, a configurao TMR oferece maior confiabilidade somente se o "tempo de misso" do sistema, utilizando TMR menor do que t0. Esse comportamento aparentemente anmalo ocorre porque, quando todos os trs componentes esto funcionando, ento TMR pode lidar com a falha de qualquer um dos componentes. No entanto, quando um componente falha, ento TMR requer que os demais componentes devam funcionar corretamente para que o sistema funcione corretamente. O MTTF de um sistema TMR : Este reduzido para: Assim, o MTTF de um TMR menor do que o MTTF de seus componentes. Isso mostra claramente que o trabalho com meios ou MTTF tem suas armadilhas. A funo de confiabilidade para TMR d uma imagem mais clara, ou seja, TMR mais confivel por perodos curtos, mas menos confivel se as duraes da execuo so grandes. 1.4.4 Disponibilidade Em um sistema real, se um componente falha, ele reparado ou substitudo por um novo componente. Quando este componente falha substitudo por outro, e assim por diante. O componente reparado novo com a sua prpria distribuio. Durante um longo perodo de tempo, um componente pode ser considerado como sendo de um dos dois estados: Trabalhando ou em reparo. O estado trabalhando significa que o componente atual operacional, e o estado em reparo significa que ele falhou e ainda no foi substitudo por um novo componente. Em caso de falha, o sistema vai de "trabalhando" para "em reparo", e quando a substituio for realizada, ele vai voltar para o estado de "trabalhando". Em tais situaes, a disponibilidade uma medida que frequentemente usada para descrever o comportamento do sistema. Definio. A disponibilidade instantnea, A(t), de um componente definida como a probabilidade de que o componente est funcionando corretamente no tempo t. Em disponibilidade, estamos interessados na probabilidade de uma instncia de tempo determinado. Na falta de reparo ou substituio, a disponibilidade simplesmente igual confiabilidade. Ou seja, a disponibilidade no momento t nada, mas R(t). No entanto, com a substituio, a vida de um componente pode ser visto como uma sequncia de variveis aleatrias independentes, cada um representando a vida do componente at a prxima falha (e reparao). Um componente pode ser representado por uma sequncia de variveis aleatrias: Tis e Dis. A varivel aleatria Ti representa a durao do perodo de ith, funcionamento e Di representa o tempo de inatividade para a ith reparao ou substituio. Na anlise de disponibilidade, que se interessaram na disponibilidade de estado estacionrio, ou disponibilidade, aps um perodo de tempo suficientemente longo. Para isso, limitando a disponibilidade de definir como o limite de A(t) como infinitas abordagens t. A disponibilidade de limitao o que comumente referido como a disponibilidade de um sistema. Note que, ao contrrio de confiabilidade cujo valor limite quando t tende ao infinito zero, limitando a disponibilidade geralmente diferente de zero. Se o tempo mdio at a falha de um componente MTTR (ou seja, cada Ti tem MTTR como a mdia), ento a disponibilidade, , dada por [Tri82]:

Esta uma expresso geral para limitar a disponibilidade no depende da natureza de outras distribuies exponenciais. Muitas vezes, na anlise de sistemas que empregam tolerncia a falhas, disponibilidade definida como a frao de tempo em que o sistema est disponvel para o trabalho "til". Se

partirmos do pressuposto que todo o tempo o sistema est operacional ele est disponvel para trabalho til, a expresso acima da disponibilidade segura. No entanto, muitos sistemas tolerantes a falhas requerem que o sistema executem vrias atividades extras para suportar a tolerncia a falhas. Estas atividades no precisam ser executadas se nenhuma tolerncia a falhas foi implementada. Em tais situaes, essas atividades extras so sobrecarga no apoio de tolerncia a falhas, e no so consideradas como trabalho til. Analise de disponibilidade se torna mais complicada em tais situaes, uma vez que estas despesas usam alguma parte do tempo quando o sistema est operacional para realizar atividades que no so consideradas teis. 1.5 RESUMO Este captulo apresentou o tema da computao tolerante a falhas. A tolerncia a falhas til em sistemas onde a alta confiabilidade necessria. Como a insegurana causada pela presena de falhas no sistema, o objetivo de tolerncia a falhas evitar a falha do sistema, apesar da presena de falhas. Isto complementar a abordagem de preveno de falhas, no qual o objetivo minimizar a presena de falhas no sistema. Onde tcnicas de preveno falhas no conseguem eliminar completamente as falhas no sistema, para aumentar a confiabilidade de um sistema, alm do que pode ser conseguido atravs de tcnicas de preveno de falhas, tolerncia a falhas empregado. As tcnicas de tolerncia a falhas baseiam-se no uso da redundncia para mascarar o efeito das falhas no sistema. Um sistema definido como sendo composto de muitos componentes, cada componente a ser um sistema em seu prprio direito. No nvel mais baixo so componentes atmicos ou sistema que no pode mais ser dividida, ou cuja estrutura interna no de interesse. As especificaes do sistema definem o comportamento correto do sistema. Uma falha de um sistema ocorre quando o sistema no pode fornecer o servio desejado (especificado). Um erro a parte do estado do sistema que pode levar falha do sistema, e uma falha a causa de um erro. Por definio, um sistema que no pode mascarar o seu prprio fracasso, se ocorrer uma falha em um sistema, o sistema falhou. O objetivo de um sistema tolerante a falhas para mascarar o fracasso de alguns dos seus componentes nos nveis superiores. Ou seja, um sistema tolerante a falhas aquele que evita a falha do sistema quando algum de seus componentes falhar. H muitas fases de deteco de erros, confinamento de danos, recuperao de erros e tratamento de falhas e continuidade do servio. Na primeira fase, a presena de uma falha determinada pela deteco de um erro no status do sistema. A deteco de erros o ponto de partida para apoiar a tolerncia a falhas, uma estratgia de tolerncia a falhas pode ser, no mximo, to bom quanto os seus mtodos de deteco de erros de replicao so cheques, cheques de cronometragem, verificaes estruturais e de codificao, cheques, sensatez e verificaes de diagnstico. Como o erro pode ser detectado algum tempo aps a falha ter ocorrido, o prximo passo no apoio tolerncia a falhas determinar a extenso dos danos para o estado do sistema pela falha. Isso feito na fase de confinamento de danos. Para avaliao dos danos, a interao entre diferentes componentes tero de ser examinadas ou estruturadas, pois pela interao que os erros podem se propagar. O objetivo identificar alguns limites dentro dos quais a propagao do erro limitada. Esses limites podem ser dinamicamente determinados aps o erro ter sido detectado atravs do exame das interaes de componentes, ou a interao destes componentes pode ser restringida de tal modo que a propagao de erro limitada a alguns limites predefinidos. O prximo passo a recuperao de erros. Uma vez que a propagao de um erro tenha sido identificada, o erro tem de ser removido do sistema. Isto feito atravs da recuperao de erros. As duas principais tcnicas so recuperao de erros para trs e recuperao de erros para a frente. Em verses anteriores de recuperao de erros, durante o clculo normal do estado do sistema periodicamente verificado. Para a recuperao, o estado verificado do sistema restaurado. Se a falha ocorreu depois da verificao, esta reverso ir remover o erro. Em recuperao para a frente, por outro lado, nenhum estado anterior do sistema est disponvel. O objetivo fazer com que o

estado do sistema esteja livre de erros, tomando algumas medidas corretivas. Enquanto para trs a recuperao uma tcnica geral, a recuperao para frente exige um bom diagnstico sobre a natureza do erro. A ltima fase o tratamento de falhas e continuidade do servio. Nas fases anteriores, o foco era sobre a remoo de erro e erro. Mas a causa raiz de qualquer erro a falha. Embora em alguns casos, particularmente com falhas transientes, apenas a recuperao de erro pode ser suficiente, em outros, aps a recuperao de erro, devemos remover a falha que causou o erro, a fim de evitar falhas futuras. Isso feito nesta fase. A primeira falha localizada para identificar o componente defeituoso. Ento, o sistema "consertado", reconfigurando o sistema usando a redundncia built-in de tal forma que tanto o componente que falhou no utilizado ou utilizado de uma maneira diferente. Uma vez que o livro trata de atividades de software de tolerncia a falhas, uma breve descrio de tolerncia a falhas em hardware tambm foi disponibilizada no captulo. A viso geral descreve o processo de desenvolvimento de hardware, alguns modelos de falhas e algumas tcnicas comuns para fornecer tolerncia a falhas em hardware. Apesar de falhas de hardware serem frequentemente causadas por motivos fsicos, como o doping inadequado, a migrao de eltrons, as quebras de linha ou shorts, essas manifestaes so muitas vezes semelhantes. Estes so chamados de modelos de falha. O modelo de falha mais comum o stuck-at, em que alguma sada de uma porta considerado preso em 0 ou 1. Modelos de falhas so o ponto de partida de apoio a tolerncia a falhas no hardware. Para os modelos de falhas que devem ser tratadas, as tcnicas so usadas para evitar a falha do sistema. Os mtodos comuns para tolerncia a falhas em hardware modular tripla redundncia, codificao de redundncia dinmica, e circuitos de auto-verificao. Uma breve introduo sobre tcnicas de tolerncia a falhas em multiprocessadores tambm dada. Como o objetivo de qualquer sistema tolerante a falhas aumentar a confiabilidade e/ou disponibilidade de um sistema, ns tambm temos uma definio formal do que se entende por estes termos. Para variveis aleatrias, que so frequentemente utilizadas em anlises de confiabilidade e disponibilidade, restringir a ateno a distribuio exponencial, que normalmente assumida por qualquer anlise. Distribuio exponencial tem a propriedade de "memoryless", em que depois de algum tempo a distribuio do "remanescente" o mesmo que a distribuio original. Para definir a confiabilidade, a vida til de um sistema considerado como uma varivel aleatria. A vida o tempo at a falha. Confiabilidade de um sistema em um tempo definido como a probabilidade de que o sistema esteja operacional em uma instncia de tempo. A partir da funo de confiabilidade, a expectativa de vida do sistema pode ser obtida tomando a expectativa. Isto tambm chamado o tempo mdio para falha (MTTF) do sistema e uma medida comum de confiabilidade. Para a distribuio exponencial, tambm obtivemos expresses para a confiabilidade de um sistema em srie na qual os componentes so ligados em srie e o sistema falhar se qualquer um dos componentes falhar, e num sistema paralelo, no qual os componentes so ligados em paralelo, e o sistema falha somente quando todos falham. Quando um componente falha, ele geralmente reparado ou substitudo por um novo componente. Assim, durante um longo perodo de tempo, um sistema pode ser considerada em dois estados: "trabalhando" ou "em reparo". Disponibilidade instantnea de um sistema em um tempo definida como a probabilidade de que o componente est funcionando corretamente na poca. Disponibilidade diferente de confiabilidade apenas por causa do reparo do sistema. Se no houve reparo, disponibilidade instantnea ser a mesma confiabilidade do sistema. Disponibilidade de estado estacionrio (frequentemente chamado de disponibilidade) o limite da disponibilidade instantnea como o tempo tende ao infinito. Ela representa a frao de tempo em que o sistema est operacional. Se MTTF o tempo mdio at a falha do sistema, e MTTR o tempo mdio de reparo do sistema, ento a disponibilidade do sistema MTTF / (MTTF + MTTR), e independente da distribuio do tempo de vida e tempos de reparao.