Tolerncia a falhas: conceitos e exemplos

Taisy Silva Weber1 Programa de Ps-Graduao em Computao - Instituto de Informtica - UFRGS taisy@inf.ufrgs.br

Resumo
Sistemas computacionais totalmente confiveis e cem por cento disponveis: utopia ou exigncia vivel? A confiabilidade e a disponibilidade de equipamentos e servios de computao podem ser medidos quantitativamente. Vrias tcnicas de projeto podem ser usadas para aumentar o valor dessas medidas, valor que pode chegar bem prximo a cem por cento. O texto mostra que sistemas totalmente infalveis so impossveis, pois falhas so inevitveis. Mas usurios e desenvolvedores no precisam, e no devem, se conformar com equipamentos e servios de baixa qualidade, desde que dispostos a arcar com o custo do emprego de tcnicas de tolerncia a falhas.

ndice
Introduo................................................................................................................. 2 1.1 Problemas com sistemas de computao.............................................................. 3 1.2 Desafios atuais...................................................................................................... 3 1.3 Falha, erro e defeito .............................................................................................. 4 1.4 Dependabilidade ................................................................................................... 6 1.5 Medidas de confiabilidade.................................................................................... 6 2 Tcnicas para alcanar dependabilidade................................................................... 8 2.1 Tolerncia a falhas................................................................................................ 8 2.2 Fases de aplicao das tcnicas de tolerncia a falhas ......................................... 8 2.3 Mascaramento de falhas ..................................................................................... 10 3 Redundncia ........................................................................................................... 11 3.1 Redundncia de hardware................................................................................... 12 3.1.1 Redundncia de hardware passiva.............................................................. 12 3.1.2 Redundncia dinmica................................................................................ 14 3.2 Redundncia de software.................................................................................... 14 3.2.1 Diversidade................................................................................................. 15 3.2.2 Blocos de recuperao ................................................................................ 16 4 Aplicaes de Sistemas Tolerantes a Falhas .......................................................... 16
Professora orientadora do PPGC, UFRGS, coordenadora do mestrado profissional em Engenharia da Computao, UFRGS, Diretora Administrativa da Sociedade Brasileira de Computao
1

4.1 reas de Aplicao............................................................................................. 17 4.2 Sistemas de tempo real ....................................................................................... 17 4.3 Sistemas digitais de telefonia ............................................................................. 18 4.4 Sistemas de transaes........................................................................................ 18 4.5 Redes de servio locais....................................................................................... 19 4.6 Sistemas seguros................................................................................................. 20 4.7 Exemplos por rea de aplicao ......................................................................... 21 5 Concluso ............................................................................................................... 22 6 Bibliografia............................................................................................................. 22

1 Introduo
Computadores e seus programas so conhecidos por automatizarem e acelerarem uma srie de tarefas enfadonhas e repetitivas, liberando seus usurios para atividades mais criativas e gratificantes. Na prtica, os usurios se vem s voltas com atividades bastante criativas, mas nada gratificantes, de tentar recuperar dados perdidos e enfrentar equipamento fora do ar devido s mltiplas falhas a que os sistemas de computao esto sujeitos. Falhas so inevitveis, mas as conseqncias das falhas, ou seja o colapso do sistema, a interrupo no fornecimento do servio e a perda de dados, podem ser evitadas pelo uso adequado de tcnicas viveis e de fcil compreenso. O conhecimento dessas tcnicas habilita o usurio a implementar as mais simples, ou exigir dos fornecedores solues que as incorporem. Entretanto, as tcnicas que toleram falhas tem um certo custo associado. O domnio da rea auxilia usurios e desenvolvedores de sistemas a avaliar a relao custo benefcio para o seu caso especifico e determinar qual a melhor tcnica para seu oramento. Sistemas mais robustos em relao a falhas eram, at recentemente, preocupao exclusiva de projetistas de sistemas crticos como avies, sondas espaciais e controles industriais de tempo real. Com a espantosa popularizao de redes fornecendo os mais variados servios, aumentou a dependncia tecnolgica de uma grande parcela da populao aos servios oferecidos. Falhas nesses servios podem ser catastrficas para a segurana da populao ou para a imagem e reputao das empresas. Para no ser o elo fraco de uma corrente, o mais simples dos computadores deve apresentar um mnimo de confiabilidade. Conhecer os problemas, quais solues existem e qual o custo associado torna-se imprescindvel para todos que pretendem continuar usando e expandindo seus negcios fornecendo um servio computacional de qualidade aos seus clientes. Para desenvolvedores de software, projetistas de hardware e gerentes de rede o domnio das tcnicas de tolerncia a falhas torna essencial na seleo de tecnologias, na especificao de sistemas e na incorporao de novas funcionalidades aos seus projetos. O texto visa dar uma viso geral da rea, que bastante ampla. Os leitores interessados podem encontrar mais informaes na bibliografia listada no final do texto, especialmente nos livros do Pradhan [Prad96], Siewiorek [SiSw82], Jalote [Jal94] Anderson e 2

Lee [AnLe81] e Birman [Bir96], que so usados nas disciplinas de Tolerncia a Falhas na UFRGS e nos quais, em grande parte, se baseia esse texto.

1.1 Problemas com sistemas de computao

Confiabilidade e disponibilidade so cada vez mais desejveis em sistemas de computao pois dia a dia aumenta a dependncia da sociedade a sistemas automatizados e informatizados. Seja no controle de trfego terrestre e areo ou de usinas de gerao de energia, na manuteno de dados sigilosos sobre a vida e a finana de cidados e empresas, nas telecomunicao e nas transaes comerciais internacionais de todo tipo, computadores atuam ativa e continuamente. fcil imaginar que defeitos nesses sistemas podem levar a grandes catstrofes. Desde os primeiros computadores, notvel como os componentes de hardware cresceram em confiabilidade. Entretanto, o software e os procedimentos para projeto esto se tornando cada vez mais complexos e apresentando cada vez mais problemas. S a confiabilidade dos componentes de hardware no garante mais a qualidade e segurana desejada aos sistemas de computao. Como exemplo recente desses problemas pode ser citada a bem conhecida falha de projeto na unidade de ponto flutuante do Pentium, que prejudicou seu lanamento comercial. Nem todo mundo sabe entretanto que falhas de projeto so comuns no lanamento de qualquer processador e muitos bugs em microprocessadores de uso geral sequer ainda foram descobertos. Alguns outros defeitos [Lapr98] valem a pena ser mencionados: na guerra do Golfo em fevereiro de 1991 preocupantes relatos de falhas em msseis foram noticiados. Em novembro de 1992 houve um colapso no sistema de comunicao do servio de ambulncias em Londres. Em junho de 1993, durante dois dias, no foi autorizada nenhuma operao de carto de crdito em toda a Frana. Todos esses defeitos foram investigados e suas causas determinadas, mas no se tem garantia que algo semelhante no possa voltar a ocorrer a qualquer momento.

1.2 Desafios atuais

Para tornar populares solues que nos garantam a confiana que depositamos em sistemas de computao, vrios desafios devem ser vencidos:
q q

Como evitar, detectar e contornar bugs no projeto de hardware e software? Como gerenciar a altssima complexidade dos sistemas atuais de computao construdos com dezenas de chips de milhes de transistores e com software de centenas de milhares de linhas de cdigo? Como explorar paralelismo para aumentar o desempenho sem comprometer a qualidade dos resultados mesmo em caso de falha de um ou mais componentes do sistema? Como aproveitar novas tecnologias mais rpidas, baratas e eficientes (mas ainda no totalmente provadas e testadas) sem saber ainda seu comportamento em situaes inesperadas sob falha ou sobrecarga? Como aproveitar, para aplicaes crticas e para operao em tempo real, o modelo de sistemas distribudos construdos sobre plataformas no confiveis de redes, contornando os problemas de perdas de mensagens, particionamento de rede e intruso de hackers? 3

Como desenvolver computadores mveis e sistemas embarcados, garantindo confiabilidade e segurana nesses dispositivos, e assegurando simultaneamente baixo consumo de potncia, sem recorrer as tcnicas usuais de replicao de componentes que aumentam peso e volume? q Finalmente, como conciliar alta confiabilidade e alta disponibilidade com as crescentes demandas por alto desempenho? Todos esses desafios ainda permanecem sem uma soluo ideal.

1.3 Falha, erro e defeito

Vrios autores tem se ocupado da nomenclatura e conceitos bsicos da rea. Os conceitos apresentados aqui so os usados por grande parte da comunidade nacional [Web90] e foram derivados dos trabalhos de Laprie [Lapr85] e Anderson e Lee [AnLe81]. Estamos interessados no sucesso de determinado sistema de computao no atendimento da sua especificao. Um defeito (failure) definido como um desvio da especificao. Defeitos no podem ser tolerados, mas deve ser evitado que o sistema apresente defeito. Define-se que um sistema est em estado errneo ou em erro se o processamento posterior a partir desse estado pode levar a defeito. Finalmente define-se falha (ou falta) como a causa fsica ou algortmica do erro. Na figura 1 mostrada uma simplificao, adotada nesse texto, para os conceitos de falha, erro e defeito. Falhas esto associadas ao universo fsico, erros ao universo da informao e defeitos ao universo do usurio. Assim um chip de memria, que apresenta uma falha do tipo grudado-em-zero (stuck-at-zero) em um de seus bits (falha no universo fsico), pode provocar uma interpretao errada da informao armazenada em uma estrutura de dados (erro no universo da informao) e como resultado o sistema pode negar autorizao de embarque para todos os passageiros de um vo (defeito no universo do usurio). interessante observar que uma falha no necessariamente leva a um erro (aquela poro da memria pode nunca ser usada) e um erro no necessariamente conduz a um defeito (no exemplo, a informao de vo lotado poderia eventualmente ser obtida a partir de outros dados redundantes da estrutura).

universo da informao universo fsico falha

processamento posterior pode levar a defeito

erro universo do usurio

defeito
desvio da especificao

Figura 1: Modelo de 3 universos: falha, erro e defeito

Define-se latncia de falha como o perodo de tempo desde a ocorrncia da falha at a manifestao do erro devido aquela falha e latncia de erro como o perodo de tempo desde a ocorrncia do erro at a manifestao do defeito devido aquele erro. Falhas so inevitveis. Componentes fsicos envelhecem e sofrem com interferncias externas, seja ambientais ou humanas. O software, e tambm os projetos de software e hardware, so vtimas de sua alta complexidade e da fragilidade humana em trabalhar com grande volume de detalhes ou com deficincias de especificao. Existem vrias classificaes para falhas na literatura tcnica ([AnLe81], [Lapr85], [Web90], [Prad96]). As falhas aparecem geralmente classificadas em falhas fsicas, aquelas de que padecem os componentes, e falhas humanas. Falhas humanas compreendem falhas de projeto e falhas de interao. As principais causas de falhas so problemas de especificao, problemas de implementao, componentes defeituosos, imperfeies de manufatura, fadiga dos componentes fsicos alm de distrbios externos como radiao, interferncia eletromagntica, variaes ambientais (temperatura, presso, umidade) e tambm problemas de operao. Alm da causa da falha, para definir uma falha considera-se ainda: Natureza: falha de hardware, falha de software, de projeto, de operao, ... q Durao ou persistncia: permanente ou temporria q Extenso: local a um mdulo, global q Valor: determinado ou indeterminado no tempo Vem crescendo em freqncia aquelas falhas provocadas por interao humana maliciosa, ou seja, por aquelas aes que visam propositadamente provocar dados aos sistemas. Essas falhas e suas conseqncias so tratados por tcnicas de security e no por tcnicas de tolerncia a falhas. Deve ser considerado, entretanto, que um sistema tolerante a falhas deve ser tambm seguro a intruses e aes maliciosas. Falhas de software e tambm de projeto so consideradas atualmente o mais grave problema em computao crtica. Sistemas crticos, tradicionalmente, so construdos de forma a suportar falhas fsicas. Assim compreensvel que falhas no tratadas, e no previstas, sejam as que mais aborream, pois possuem uma grande potencial de comprometer a confiabilidade e disponibilidade do sistema. Um exame de estatsticas disponveis [Lapr98] confirma essas consideraes (tabela 1).
Sistemas tradicionais No tolerante a falhas Tolerante a falhas Mean time to failure: 6 a 12 semanas Mean time to failure: 21 anos Indisponibilidade aps defeito: 1 a 4 h (Tandem) Defeitos: hardware software comunicaes / ambiente operaes 50% 25% 15% 10% Defeitos: software operaes hardware ambiente 65% 10% 8% 7% Redes cliente-servidor (no tolerantes a falhas) Disponibilidade mdia: 98% Defeitos: projeto operaes fsicos 60% 24% 16% q

Tabela 1 - Causas usuais de defeitos em sistemas de computao

1.4 Dependabilidade
O objetivo de tolerncia a falhas alcanar dependabilidade (tabela 2). O termo dependabilidade uma traduo literal do termo ingls dependability, que indica a qualidade do servio fornecido por um dado sistema e a confiana depositada no servio fornecido. Principais medidas de dependabilidade [Prad96] so confiabilidade, disponibilidade, segurana de funcionamento (safety), segurana (security), mantenabilidade, testabilidade e comprometimento do desempenho (performability).
Dependabilidade (dependability) Confiabilidade (reliability) qualidade do servio fornecido por um dado sistema capacidade de atender a especificao, dentro de condies definidas, durante certo perodo de funcionamento e condicionado a estar operacional no incio do perodo probabilidade do sistema estar operacional num instante de tempo determinado; alternncia de perodos de funcionamento e reparo probabilidade do sistema ou estar operacional e executar sua funo corretamente ou descontinuar suas funes de forma a no provocar dano a outros sistema ou pessoas que dele dependam proteo contra falhas maliciosas, visando privacidade, autenticidade, integridade e irrepudiabilidade dos dados

Disponibilidade (availability) Segurana (safety)

Segurana (security)

Tabela 2 - Atributos de dependabilidade Confiabilidade a medida mais usada em sistemas em que mesmo curtos perodos de operao incorreta so inaceitveis ou em sistemas em que reparo impossvel. Exemplos so aviao e explorao espacial. Confiabilidade uma medida probabilstica, pois falhas so um fenmeno aleatrio. Confiabilidade no pode ser confundida com disponibilidade. Um sistema pode ser altamente disponvel mesmo apresentando perodos de inoperabilidade, desde que esses perodos sejam curtos e no comprometam a qualidade do servio. Outras qualidades importantes de um sistema so: comprometimento do desempenho (performability), mantenabilidade e testabilidade. Performability est relacionada queda de desempenho provocado por falhas, onde o sistema continua a operar, mas degradado em desempenho. Mantenabilidade significa a facilidade de realizar a manuteno do sistema, ou seja, a probabilidade que um sistema com defeitos seja restaurado a um estado operacional dentro de um perodo determinado. Restaurao envolve a localizao do problema, o reparo fsico e a colocao em operao. Finalmente testabilidade a capacidade de testar certos atributos internos ao sistema ou facilidade de realizar certos testes. Quanto maior a testabilidade, melhor a mantenabilidade, por conseqncia menor o tempo de indisponibilidade do sistema devido a reparos.

1.5 Medidas de confiabilidade

As medidas de confiabilidade mais usadas na prtica so: taxa de defeitos, MTTF, MTTR, MTBF. A tabela 3 mostra uma definio informal dessas medidas. Os fabricantes devem fornecer essas medidas para os seus produtos, tanto para os componentes eletrnicos, como para os sistemas de computao mais complexos. Essas medidas so determinadas pelo fabricante estatisticamente, observando o comportamento dos componentes e dispositivos fabricados.

Taxa de defeitos - failure rate, hazard function, hazard rate MTTF - mean time to failure MTTR - mean time to repair MTBF - mean time between failure

nmero esperado de defeitos em um dado perodo de tempo, assumido um valor constante durante o tempo de vida til do componente. tempo esperado at a primeira ocorrncia de defeito tempo mdio para reparo do sistema tempo mdio entre as falhas do sistema

Tabela 3 - Medidas de confiabilidade A taxa de defeitos de um componente dada por falhas por unidade de tempo e varia com o tempo de vida do componente.

taxa de defeitos mortalidade infantil

fase de envelhecimento perodo de vida til

taxa de defeitos constante

tempo Figura 2 - Curva da banheira Uma representao usual para a taxa de defeitos de componentes de hardware dada pela curva da banheira (figura 2). Na figura 2 podem se distinguir 3 fases: q mortalidade infantil: componentes fracos e mal fabricados q vida til: taxa de falhas (defeitos) constante q envelhecimento: taxa de falhas crescente Os componentes de hardware s apresentam taxa de defeitos constante durante um perodo de tempo chamado de vida til, que segue uma fase com taxa de falhas decrescente chamada de mortalidade infantil. Para acelerar a fase de mortalidade infantil, os fabricantes recorrem a tcnicas de burn-in, onde efetuada a remoo de componentes fracos pela colocao dos componentes em operao acelerada antes de coloc-los no mercado ou no produto final. questionvel se a curva da banheira pode ser aplicada tambm para componentes de software. Pode ser observado, no entanto, que os componentes de software tambm apresentam uma fase de mortalidade infantil ou taxa de erros alta no incio da fase de testes, que decresce rapidamente at a entrada em operao do software. A partir desse momento, o software apresenta um taxa de erros constante at que, eventualmente, precise sofrer alguma alterao ou sua plataforma de hardware se torne obsoleta. Nesse momento, a taxa de erros volta a crescer. Intencionalmente mencionamos taxa de erros para software e no defeitos, porque erro o termo usualmente empregado quando se trata de programas incorretos.

2 Tcnicas para alcanar dependabilidade

No desenvolvimento de um sistema com os atributos de dependabilidade desejados, um conjunto de mtodos e tcnicas devem ser empregadas. Esses mtodos e tcnicas so classificados conforme a tabela 3.
preveno de falhas tolerncia a falhas impede a ocorrncia ou introduo de falhas. Envolve a seleo de metodologias de projeto e de tecnologias adequadas para os seus componentes fornece o servio esperado mesmo na presena de falhas. Tcnicas comuns: mascaramento de falhas, deteco de falhas, localizao, confinamento, recuperao, reconfigurao, tratamento remoo de falhas, verificao da presena de falhas estimativas sobre presena de falhas e estimativas sobre conseqncias de falhas

validao previso de falhas

Tabela 3 - Tcnicas para alcanar dependabilidade

2.1 Tolerncia a falhas

Preveno e remoo de falhas no so suficientes quando o sistema exige alta confiabilidade ou alta disponibilidade. Nesses casos o sistema deve ser construdo usando tcnicas de tolerncia a falhas. Essas tcnicas garantem funcionamento correto do sistema mesmo na ocorrncia de falhas e so todas baseadas em redundncia, exigindo componentes adicionais ou algoritmos especiais. Tolerncia a falhas no dispensa as tcnicas de preveno e remoo. Sistemas construdos com componentes frgeis e tcnicas inadequadas de projeto no conseguem ser confiveis pela simples aplicao de tolerncia a falhas. O conceito de tolerncia a falhas foi apresentado originalmente por Avizienis em 1967 [Aviz98]. Entretanto estratgias para construo de sistemas mais confiveis j eram usadas desde a construo dos primeiros computadores [VonN56]. Apesar de envolver tcnicas e estratgias to antigas, a tolerncia a falhas ainda no uma preocupao rotineira de projetistas e usurios, ficando sua aplicao quase sempre restrita a sistemas crticos. As tcnicas de tolerncia a falhas so de duas classes disjuntas: q mascaramento ou q deteco, localizao e reconfigurao Na primeira classe, mascaramento, falhas no se manifestam como erros, pois so mascaradas na origem. A primeira classe geralmente emprega mais redundncia que a segunda e, por no envolver os tempos gastos para as tarefas de deteco, localizao e reconfigurao, a preferida para sistemas de tempo real crticos.

2.2 Fases de aplicao das tcnicas de tolerncia a falhas

Vrios autores apresentaram suas prprias classificaes para as tcnicas de tolerncia a falhas. A mais comum a classificao em 4 fases de aplicao [AnLe81]: deteco, confinamento, recuperao e tratamento. Essas fases excluem mascaramento de falhas, que uma tcnica a parte, no usada em complemento s demais.

Fases deteco de erros

confinamento e avaliao

recuperao de erros tratamento da falha

Mecanismos replicao testes de limites de tempo co de guarda (watchdog timers) testes reversos codificao: paridade, cdigos de deteco de erros, Hamming, ... teste de razoabilidade, de limites e de compatibilidades testes estruturais e de consistncia diagnstico aes atmicas operaes primitivas auto encapsuladas isolamento de processos regras do tipo tudo que no permitido proibido hierarquia de processos controle de recursos tcnicas de recuperao por retorno (backward error recovery) tcnicas de recuperao por avano (forward error recovery) diagnstico reparo

Tabela 4 - Quatro fases de Anderson e Lee As fases envolvem o conceito de uma seqncia complementar de atividades, que devem ser executadas aps a ocorrncia de uma ou mais falhas. Alguns autores consideram as fases extras de diagnstico e mascaramento. Ns preferimos considerar o mascaramento de falhas como uma classe a parte, no complementar s fases citadas. Diagnstico, por outro lado pode ser usado tanto como um mecanismo usado nas fases de deteco de erros e de localizao de falhas, como uma tcnica isolada conduzida periodicamente para diminuir a latncia. A primeira fase de Anderson e Lee a de deteco de um erro. Uma falha primeiro se manifesta como um erro, para ento ser detectada por alguns dos mecanismos listados na tabela 4. Antes da sua manifestao como erro, a falha est latente e no pode ser detectada, eventualmente a falha pode permanecer no sistema durante toda a sua vida til sem nunca se manifestar, ou seja, sem nunca levar o sistema a um estado errneo. Devido a latncia da falha, aps a ocorrncia da falha at o erro ser detectado, pode ter ocorrido espalhamento de dados invlidos. O confinamento estabelece limites para a propagao do dano, mas depende de decises de projeto; os sistemas por sua natureza no provm confinamento. Durante o projeto devem ser previstas e implementadas restries ao fluxo de informaes para evitar fluxos acidentais e estabelecer interfaces de verificao para deteco de erros. A recuperao de erros ocorre aps a deteco e envolve a troca do estado atual incorreto para um estado livre de falhas. Pode ser de duas formas (tabela 5): tcnicas de recuperao por retorno (backward error recovery) e tcnicas de recuperao por avano (forward error recovery.
Tcnica Definio Caractersticas Implementao especfica a cada sistema

forward error conduo a novo estado ainda eficiente, mas danos recovery no ocorrido desde a ltima devem ser previstos manifestao de erro acuradamente backward error conduo a estado anterior alto custo, mas de aplicao genrica

pontos de verificao (checkpoints), pistas de

recovery

auditoria (audit trails), ...

Tabela 5 - Tcnicas de recuperao A recuperao simples para um sistema com um nico processo, mas complexa em processamento distribudo [Jans97]. A recuperao nesses sistemas, usualmente de retorno pode provocar efeito domin. Ao desfazer a computao, um processo deixa algumas mensagens rfs na rede. Processos que receberam e incorporaram essas mensagens devem por sua vez desfazer tambm a computao realizada, provocando que, eventualmente, outros processos, que receberam suas mensagens, agora rfs, tambm tenham que desfazer suas computaes. O efeito pode atingir todos os processos de um sistema e provocar o retorno ao incio do processamento. Uma soluo para esse problema impor restries a comunicao entre os processos. Tcnicas de recuperao por retorno no so adequadas a sistemas de tempo real. Nesses sistemas deve ser usada recuperao por avano. A ltima fase, tratamento de falhas, consiste em: localizar a origem do erro (falha), q localizar a falha de forma precisa, q reparar a falha, q recuperar o restante do sistema. Nessa fase geralmente considerada a hiptese de falha nica, ou seja, uma nica falha ocorrendo a cada vez. A localizao da falha realizada em duas etapas: localizao grosseira (mdulo ou subsistema) e rpida e localizao fina, mais demorada, onde o componente falho determinado. Para os dois tipos diagnstico usado. O diagnstico um teste com comparao dos resultados gerados com os resultados previstos. Pode ser conduzido no sistema de forma manual ou automtica: manual - executado por um operador local ou remoto, q automtico - executado pelos os componentes livres de falha. Aps a localizao, a falha reparada atravs da remoo do componente danificado. Tambm o reparo pode ser manual ou automtico. O reparo automtico pode envolver degradao gradual, ou seja, uma reconfigurao para operao com menor nmero de componentes, ou a substituio imediata por outro componente disponvel no sistema. Substituio automtica usada em sistemas com longo perodo de misso sem possibilidade de reparo manual, como por exemplo em sondas espaciais e satlites.
q q

2.3 Mascaramento de falhas

O mascaramento de falhas garante resposta correta mesmo na presena de falhas. A falha no se manifesta como erro, o sistema no entra em estado errneo e, portanto, erros no precisam ser detectados, confinados e recuperados. Entretanto, em caso de falhas permanentes, a localizao e o reparo da falha ainda so necessrios. A tabela 6 mostra mecanismos usuais para implementao de mascaramento de falhas. Alguns desses mecanismos sero vistos em detalhes na prxima seo.

10

mascaramento de falhas

redundncia de hardware (replicao de componentes) codificao: ECC (cdigo de correo de erros) diversidade, programao diversitria (n-verses) blocos de recuperao

Tabela 6 - Mecanismos para mascarar falhas

3 Redundncia
Redundncia a palavra mgica em tolerncia a falhas. Redundncia para aumentar confiabilidade quase to antiga como a histria dos computadores ([Crev56], [VonN56]). Todas as tcnicas de tolerncia a falhas envolvem alguma forma de redundncia. Redundncia est to intimamente relacionada a tolerncia a falhas que na indstria nacional o termo usado para designar um sistema tolerante a falhas sistema redundante. Redundncia para tolerncia a falhas pode aparecer de vrias formas: Redundncia de hardware q Redundncia de software q Redundncia de informao q Redundncia de tempo As tcnicas de redundncia de hardware e de software so apresentadas nas prximas sees. Redundncia de informao provida por cdigos de correo de erros, como ECC. ECC (error correction code) est sendo exaustivamente usado em memrias e em transferncia entre memrias e processadores. Como a codificao da informao implica no aumento do nmero de bits, e os bits adicionais no aumentam a capacidade de representao de dados do cdigo, fcil perceber a razo da codificao tambm ser considerada uma forma de redundncia. Redundncia temporal repete a computao no tempo. Evita custo de hardware adicional, aumentando o tempo necessrio para realizar uma computao. usada em sistemas onde tempo no crtico, ou onde o processador trabalha com ociosidade. Aplicaes usuais da redundncia temporal: deteco de falhas transientes: repetindo a computao, resultados diferentes so uma forte indicao de uma falha transitria. Essa estratgia no adequada para falhas permanentes, porque os resultados repetidos nesse caso sero iguais. q deteco de falhas permanentes: repete-se a computao com dados codificados e decodifica-se o resultado antes da comparao com o resultado anterior. Essa estratgia provoca a manifestao de falhas permanentes. Por exemplo, considere um barramento com uma linha grudada em zero. Nas duas computaes, uma transferncia com dado normal; e a segunda com dado invertido, por exemplo, a linha vai transferir sempre zero. Todas essas formas de redundncia, de hardware, de software, temporal de informao, tem algum impacto no sistema, seja no custo, no desempenho, na rea (tamanho, peso), ou na potncia consumida. Assim, apesar de ser a soluo "mgica" para tolerncia a falhas, o uso de redundncia em qualquer projeto deve ser bem ponderada. Redundncia tanto serve para deteco de falhas, como para mascaramento de falhas. O grau de redundncia em cada caso diferente. Para mascarar falhas so necessrios 11
q q

mais componentes do que para detectar falhas. Por exemplo, para detectar falhas em um microprocessador necessrio outro microprocessador idntico, sincronizado ao primeiro, alm de um comparador de sinais na sada de ambos. Qualquer diferena na comparao indica que o par de microprocessadores est em desacordo, e que portanto um dos dois est falho. Entretanto est falha no pode ser mascarada. O resultado da comparao no indica quais as sadas so as corretas.

3.1 Redundncia de hardware

Redundncia de hardware est baseada na replicao de componentes.
redundncia de hardware redundncia passiva ou esttica redundncia ativa ou dinmica redundncia hbrida tcnicas mascaramento de falhas deteco, localizao e recuperao combinao de ativa e passiva vantagens no requer ao do sistema, no indica falha substituio de mdulos, usada em aplicaes de longa vida usada para garantir mascaramento e longa vida; geralmente de alto custo

Tabela 7 - Redundncia de hardware 3.1.1 Redundncia de hardware passiva

Na redundncia de hardware passiva os elementos redundantes so usados para mascarar falhas. Todos os elementos executam a mesma tarefa e o resultado e determinado por votao. Exemplos so TMR (triple modular redundancy) e NMR. TMR, redundncia modular tripla, uma das tcnicas mais conhecidas de tolerncia a falhas. TMR mascara falha em um componente de hardware triplicando o componente e votando entre as sadas para determinao do resultado (figura 3). A votao pode ser

3 mdulos de hardware

ponto crtico de falha (single point of failure )

VOTADOR

resultado

votador em software ou hardware ?

por maioria ou por valor mdio

por maioria (2 em 1) ou votao por seleo do valor mdio [LyVa62]. Figura 3 - TMR 12

O votador realiza uma funo simples, fcil de verificar a correo. interessante observar que o votador no tem a funo de determinar qual o mdulo de hardware discorda da maioria. Se esse funo for necessria no sistema, ela deve ser realizada por um detector de falhas. Apesar de simples, o votador, por estar em srie com os mdulos de hardware e ter a responsabilidade de fornecer o resultado, o ponto crtico de falhas no esquema TMR. Se o votador apresentar baixa confiabilidade, todo o esquema vai ser frgil, to frgil como o votador. Solues para contornar a fragilidade do votador so: Construir o votador com componentes de alta confiabilidade. q Triplicar o votador. q Realizar a votao por software. A figura 4 mostra um esquema com votador triplicado. Os 3 resultados gerados podem, nesse caso, ser levados aos prximos 3 mdulos de hardware do sistema. Deve ser observado que a redundncia aumenta o nmero de componentes do sistema. Quando maior o nmero de componentes, maior possibilidade de falha.
VOTADOR q

resultados
VOTADOR

VOTADOR

3 mdulos de hardware
votador triplicado

Figura 4 - TMR com votador triplicado TMR apresenta uma confiabilidade maior que um sistema de um nico componente at a ocorrncia da primeira falha permanente (figura 5). Depois disso, perde a capacidade de mascarar falhas e vai apresentar uma confiabilidade menor que um sistema de um nico componente. Com o tempo, quando aumenta a probabilidade de componentes falharem (ou seja aumenta a taxa de defeitos) TMR apresenta uma confiabilidade pior do que um sistema no redundante. TMR ideal ento para perodos no muito longos de misso. Suporta uma falha permanente apenas e ideal para falhas temporrias, uma de cada vez.

13

R(t)

TMR

redundncia aumenta nmero de componentes do sistema

no redundante

durao da misso Figura 5 - Confiabilidade de TMR Redundncia modular mltipla, NMR, a generalizao do conceito de TMR. Ou seja, TMR um caso especial de NMR. O computador de bordo do Space Shuttle um exemplo de NMR, com n igual a 4 e votao por software. 3.1.2 Redundncia dinmica

Na redundncia dinmica ou ativa, tolerncia a falhas provida pelo emprego das tcnicas de deteco, localizao e recuperao. A redundncia empregada neste caso no prov mascaramento. Redundncia dinmica usada em aplicaes que suportam permanecer em um estado errneo durante um curto perodo de tempo, tempo esse necessrio para a deteco do erro e recuperao para um estado livre de falhas. Um exemplo de implementao de redundncia dinmica atravs de mdulos estepe (standby sparing). Mdulos estepe podem ser operados de duas formas conforme tabela 8.
Operao de mdulos estepe comentrios alimentados (hot standby) no alimentados (cold standby) Mdulo estepe conectado eletricamente ao sistema. Minimiza a descontinuidade do processamento durante o chaveamento entre os mdulos. Mdulo estepe s comea a operar quando conectado. Aumenta a vida til dos mdulos estepe.

Tabela 8 - Exemplo de redundncia dinmica

3.2 Redundncia de software

A simples replicao de componentes idnticos uma estratgia intil em software. Componentes idnticos de software vo apresentar erros idnticos. Assim no basta copiar um programa e execut-lo em paralelo ou executar o mesmo programa duas vezes. Exemplos de outras formas de redundncia em software:
q

diversidade (ou programao n-verses)

14

blocos de recuperao q verificao de consistncia interessante lembrar que se o software foi projetado corretamente desde o incio, ento no so necessrias tcnicas de tolerncia a falhas para software. Infelizmente estamos longe de poder garantir, na prtica, programas corretos. 3.2.1 Diversidade

Diversidade, tambm chamada programao diversitria, uma tcnica de redundncia usada para obter tolerncia a falhas em software ([ChAv78], [AvKe84], [WeWe89]). A partir de um problema a ser solucionado so implementadas diversas solues alternativas, sendo a resposta do sistema determinada por votao (figura 6). verso 1 verso 2 resultado
VOTADOR

verso n

erros devem se manifestar de forma diferente nas verses

Figura 6 - Programao n-verses A aplicao da tcnica no leva em conta se erros em programas alternativos apresentam a mesma causa (por exemplo: falsa interpretao de uma especificao ou uma troca de um sinal em uma frmula). Os erros, para poderem ser detectados, devem necessariamente se manifestar de forma diferente nas diversas alternativas, ou seja, devem ser estatisticamente independentes. Experimentos comprovam que o nmero de manifestaes idnticas (erros que assim no seriam detectados) significativamente menor que o nmero total de erros [KLJ85]. Diversidade pode ser utilizada em todas as fases do desenvolvimento de um programa, desde sua especificao at o teste, dependendo do tipo de erro que se deseja detectar (erro de especificao, de projeto, ou de implementao). Essa tcnica chamada de projeto diversitrio quando o desenvolvimento do sistema realizado de forma diversitria e de programao em n-verses quando se restringe implementao do sistema. Pode ser tambm usada como tcnica de preveno de falhas. Nesse ltimo caso, vrias alternativas de projeto ou de implementao so desenvolvidas para que, na fase de teste, erros eventuais possam ser localizados e corrigidos de uma forma mais simples e efetiva. No final da fase de teste, ento escolhida a alternativa em que se detectou a menor ocorrncia de erros, e apenas esta alternativa integrada ao sistema. A facilidade no reconhecimento de erros na fase de teste do sistema, a tolerncia tanto de falhas intermitentes quanto de permanentes e a atuao potencial tambm contra erros externos ao sistema (como por exemplo erros do compilador, do sistema operacional e at mesmo falhas de hardware) so vantagens atribudas a programao

15

diversitria. Entretanto desvantagens da tcnica tambm devem ser citadas, como o aumento dos custos de desenvolvimento e manuteno, a complexidade de sincronizao das verses e o problema de determinar a correlao das fontes de erro. Enquanto pode ser provado formalmente que a redundncia de elementos de hardware aumenta a confiabilidade do sistema, tal prova no existe para a diversidade em software. Vrios fatores influenciam a eficcia da programao diversitria: as equipes podem trocar algoritmos entre si, os membros das equipes podem por formao tender a adotar os mesmos mtodos de desenvolvimento, ou as equipes podem buscar suporte nas mesmas fontes. Qualquer uma dessas correlaes imprevisveis se constitui uma fonte potencial de erros. Um exemplo de diversidade o sistema de computadores de bordo do Space Shutle. Quatro computadores idnticos so usados em NMR. Um quinto computador, diverso em hardware e em software dos outros quatro, pode substituir os demais em caso de colapso do esquema NMR [Prad96]. 3.2.2 Blocos de recuperao

Semelhante a programao a n-verses, mas nessa tcnica programas secundrios s sero necessrios na deteco de um erro no programa primrio. Essa estratgia envolve um teste de aceitao (figura 7). Programas so executados e testados um a um at que o primeiro passe no teste de aceitao. A estratgia de blocos de recuperao tolera n-1 falhas, no caso de falhas independentes nas n verses.
verses secundrias s so necessrias se for detectado erro no primrio

resultado
verso primria verso secundria 1 chave n para 1 teste de aceitao

verso secundria n-1

programas so executados e testados um a um at o primeiro passar no teste de aceitao

Figura 7 - blocos de recuperao

4 Aplicaes de Sistemas Tolerantes a Falhas

As tcnicas apresentadas nas sees anteriores podem sugerir a possibilidade da construo de um sistema perfeitamente confivel e permanentemente disponvel. Infelizmente, estas tcnicas apenas aumentam a dependabilidade de um sistema, no fornecendo nenhuma garantia de que todas as falhas possveis possam ser toleradas. A

16

redundncia inerente tolerncia a falhas aumenta consideravelmente o custo de um sistema de computao. S esse acrscimo de custo j implica no estabelecimento de fronteiras claras ao emprego indiscriminado de tcnicas de tolerncia a falhas. Para a escolha adequada de um sistema de computao tolerante a falhas, as caractersticas especiais da aplicao e as suas exigncias quanto a confiabilidade e disponibilidade devem ser conhecidas em detalhe. S obedecendo criteriosamente s exigncias essenciais de cada aplicao torna-se possvel contornar o custo associado ao emprego de tcnicas de tolerncia a falhas.

4.1 reas de Aplicao

As reas tradicionais onde so empregados sistemas tolerantes a falhas so: aplicaes crticas de sistemas de tempo real como medicina, controle de processos e transportes areos q aplicaes seguras de tempo real como transportes urbanos; q aplicaes em sistemas de tempo real de longo perodo de durao sem manuteno, como em viagens espaciais, satlites e sondas; q aplicaes tcnicas como telefonia q aplicaes comerciais como sistemas de transao e redes locais. Essas reas no abrangem todo o universo de aplicaes onde tolerncia a falhas pode ser empregada com vantagens para o usurio de sistemas de computao. Exigncias quanto a disponibilidade e confiabilidade so encontradas em qualquer rea. Usurios, que inicialmente se mostram satisfeitos em contar apenas com a simples automao de servios, logo passam a desejar que esses servios sejam prestados corretamente e sem interrupes. Sistemas tolerantes a falhas so caros e portanto empregados apenas naquelas situaes em que a sua no utilizao acarretaria prejuzos irrecuperveis. No mercado brasileiro as reas tradicionais de aplicao de tolerncia a falhas so telefonia e pesquisas espaciais. A Telebrs e o INPE so exemplos de instituies que vm desenvolvendo trabalhos de pesquisa no sentido de gerar tecnologia nacional em tolerncia a falhas para as reas de telefonia e pesquisas espaciais respectivamente.
q

4.2 Sistemas de tempo real

Sistemas de computao de tempo real so aplicados no controle, superviso e automao (controle de processos industriais, transportes, medicina) e em comunicao. Condies de para aplicao desses sistemas so:
q

Disponibilidade de apenas um curto intervalo de tempo para reconhecimento de erros, de forma a no prejudicar o processamento em tempo real; q Impossibilidade de emprego de recuperao por retorno, uma vez que eventos passados no so reproduzveis em sistemas de tempo real; q Exigncia de redundncia esttica para garantir a continuidade do processamento em tempo real em caso de falha de um componente;

17

Comportamento livre de falhas (fail-safe), ou seja, em caso de ocorrncia de uma falha no mascarvel, o sistema deve ir imediatamente para um estado seguro. Como exemplos de sistemas de tempo real tolerantes a falhas podemos citar os sistemas FTMP [HSL78] e SIFT [Wens78], que foram especificados pela NASA para serem usados como computadores de bordo, e o sistema August System: Series 300 [Wens83] derivado do computador SIFT. O August 300, ao contrrio de SIFT, no um computador de bordo, mas uma mquina para controle de processos em tempo real. O sistema de computao de bordo do Space Shuttle outro exemplo de sistema tempo real tolerante a falhas inspirado no SIFT.

4.3 Sistemas digitais de telefonia

Sistemas eletrnicos para telefonia, devido a rigorosas exigncias quanto disponibilidade, tradicionalmente empregam tcnicas de tolerncia a falhas. Sistemas de telefonia devem apresentar alta disponibilidade. especificado um tempo mximo em falha no maior que 2 horas em 30 anos. Junto ao uso de componentes de alta qualidade e longa vida, requisitos para a aplicao nessa rea so: Deteco e localizao automtica de erros tanto de software como de hardware; q Tratamento automtico de erros por reconfigurao do sistema; q Isolamento e substituio de componentes faltosos durante o perodo de operao normal do sistema. A principal tcnica de tolerncia a falhas, presente nos processadores em sistemas telefnicos, tem sido duplicao de componentes. Duplicao usada para substituio de componentes com falhas permanentes e tambm para deteco de erros, onde ento duas unidades executam de forma sincronizada e um comparador verifica os resultados. Alm disso tambm usada uma grande variedade de tcnicas de tolerncia a falhas, como cdigos de deteco e correo de erros, memria duplicada, temporizadores para deteco de time-out, componentes estepe, auto-teste, canal de manuteno, ... Os mais antigos exemplos so os computadores ESS da AT&T [Toy78], no mercado desde 1965. Inicialmente o sistema ESS era formado por simples controladores de tempo real dedicados; atualmente so complexos sistemas de propsito geral combinando hardware e software sofisticado. Todos computadores ESS so, entretanto, construdos usando a tcnica de duplicao-comparao. Outros exemplos de computadores para telefonia so os sistemas EDS e o SSP113, da Siemens. O SSP113 uma mquina multiprocessadora construda com microprocessadores de 32 bits e, como os demais exemplos citados, emprega exaustivamente duplicao de elementos.
q

4.4 Sistemas de transaes

Um nmero significativo de aplicaes comerciais so realizados sob forma de processamento de transaes. Esse processamento implica na existncia de uma base de dados comum usada interativa e concorrentemente por um grande nmero de usurios atravs de terminais de acesso. Exemplos so bancos de dados para aplicaes

18

financeiras, bancarias e de bolsa de valores, e para reserva internacional de vos. Requisitos indispensveis para aplicaes nessa rea so: Garantia de integridade e consistncia de dados na base de dados; q Alta disponibilidade para o processamento contnuo de transaes. Adicionalmente aos requisitos citados, so caractersticas desejveis: Tratamento automtico de erros no processamento de transaes e de erros de hardware, sem interrupo do funcionamento normal; q Reconfigurao tanto de hardware como de software, sem interrupo do processamento normal. Integridade e consistncia de dados so os requisitos mais importantes. Disponibilidade assim como tratamento de erros e reconfigurao sem interrupo do funcionamento podem at ser sacrificados, se for para garantir a correo na base de dados. A maioria dos sistemas comerciais de transaes operam baseados no modelo fail-stop. Em caso de erro, o sistema interrompe o processamento evitando assim a propagao do erro com conseqente dano base de dados. A partir da introduo dos sistemas NonStop [Katz78] no final da dcada de 70, a firma Tandem Computers (fundada em 1976) foi durante muito tempo lder do mercado de sistemas tolerantes a falha comerciais. Forte concorrente para a Tandem foi a Stratus Computers [Hend83], fundada em 1980, com o sistema Continuous Processing. Modelos desse sistema foram tambm comercializados por outros fornecedores, com os nomes de Olivetti CPS32 e IBM/88. Tandem e Stratus so tambm dois bons exemplos da aplicao de mecanismos de tolerncia a falhas implementados em software (Tandem) e em hardware (Stratus). Stratus, por implementar tolerncia a falhas em hardware e assim tornar os mecanismos transparentes s aplicaes, acabou por suplantar a Tandem como lder no mercado. Outros exemplos de computadores comerciais de transaes de alta disponibilidade so: VAX 8600, IBM 3090, VAXft 3000 (1990), Teradata (computadores baseados na famlia Intel 80x86) e Sequoia (baseados na famlia Motorola 68000).
q q

4.5 Redes de servio locais

Redes locais so formadas por estaes de trabalho e por um ou mais servidores de rede que se comunicam por trocas de mensagens. O servidor responsvel por servios de suporte e controle da rede local como armazenamento de dados e arquivos, gerenciamento de documentos, impresso de documentos e conexo a outras redes. Redes locais se tornaram, nos ltimos tempos, a plataforma de computao mais popular em corporaes, centros de pesquisa e universidades, substituindo com vantagens mainframes e terminais. notvel sua aceitao tambm e tambm em automao industrial. Requisitos quanto a tolerncia a falhas para aplicaes nessa rea so semelhantes aos requisitos para sistemas de transao:
q

Garantia de integridade e redundncia de dados; q Alta disponibilidade do servidor para prover continuidade de servios na rede; 19

Tratamento automtico de erros de hardware e no servio da rede; q Reconfigurao da rede em caso de erro e estabelecimento de uma nova configurao com a entrada de outras estaes (clientes e servidores), sem interrupo do processamento normal. Com o aumento de popularidade das redes e com o crescimento do comrcio eletrnico o mercado para servidores de redes tolerantes a falhas aumentou consideravelmente. Praticamente todos os fabricantes de computadores oferecem servidores de redes tolerantes a falhas, entre eles se destacam Sun Microsystems (com a srie Enterprise), Compac (com tecnologia Tandem), e Stratus. Os servidores comerciais so baseados em redundncia de componentes de hardware, troca de mdulos sem necessidade de desligar o sistema, espelhamento de disco ou RAID e sistemas operacionais convencionais como UNIX. Um exemplo linha Sun Enterprise X500, com altos ndices de disponibilidade e confiabilidade [http://www.sun.com]. Algumas caractersticas gerais presentes nos servidores Sun Enterprise so mostradas na tabela 8.
Reconfigurao automtica possibilita ao sistema reiniciar imediatamente aps um defeito, desabilitando automaticamente o componente falho. Envolve testes nos vrios componentes do sistema a cada vez que o equipamento ligado ou quando gerada uma interrupo externa. Fontes de energia e ventilao redundantes ECC para garantir integridade dos dados Monitoramento ambiental defeitos nesses componentes no interrompem a operao do sistema ECC (error correction code) usado em todos os caminhos de dados. Adicionalmente, paridade usada nos endereos e linhas de controle do barramento e tambm nas caches interna e externa dos processadores. para proteger o sistema contra defeitos causados por temperaturas extremas, pela falta de fluxo de ar atravs do sistema ou devido a flutuaes de energia. vrios registradores e contadores que so usados para monitorar a atividade do sistema e fornecer mecanismos de co de guarda (watchdog) em hardware. Os registradores so acessados por software especial, como o Solstice SyMON, para extrao de dados relativos a performance e manuteno. Sun Validation Test Suite (SunVTS) realiza testes e registra os resultados obtidos. Os testes podem ser realizados tanto em componentes (processadores, memria, I/O,), como no sistema como um todo habilidade em substituir componentes sem necessidade de desligar o sistema (hot swap). Mdulos de energia/ventilao, placas de CPU/memria e placas de I/O podem ser instalados e removidos com sistema em operao norma;.

Ferramentas de monitoramento avanadas

Ferramentas de diagnstico online Troca de componentes com o sistema em operao

Tabela 8 - Caractersticas da srie Sun Enterprise

4.6 Sistemas seguros

Por sistemas seguros so designados os sistemas em que segurana mais importante que disponibilidade. Exemplos tpicos so sistemas de transportes urbanos, que devem

20

apresentar um comportamento fail-safe. Em caso de erro o sistema deve ir imediatamente para um estado seguro. relativamente fcil parar trens para evitar colises. O estado parado um estado seguro para transporte urbano. Requisitos quanto a tolerncia a falhas para aplicaes nessa rea so aproximadamente semelhantes aos requisitos para sistemas de tempo real, uma vez que o controle desse tipo de sistema tambm ocorre em tempo real: q Existncia de um estado seguro e facilidade de alcan-lo em caso de erro; q Rapidez no reconhecimento de erros; q Redundncia para mascaramento e para reconhecimento de erros. Para aplicaes em transportes urbanos como bondes, trens subterrneos e de superfcie, utilizados largamente na Europa, foi desenvolvida na Alemanha uma famlia de microprocessadores, SIMIS [Goer89], que facilita a implementao de sistemas seguros. Todos os componentes so construdos para operar de forma duplicada. Em caso de discordncia de qualquer sada, qualquer processamento ou distribuio de sinal posterior bloqueado, e os sinais de sada do sistema so colocados em zero. O sistema projetado para, quando ocorrer o bloqueio dos componentes, ir imediatamente para um estado seguro.

4.7 Exemplos por rea de aplicao

A tabela 9 resume as reas de aplicao apresentadas anteriormente citando alguns exemplos por rea. Essa lista de aplicaes e exemplos no exaustiva. Cresce dia a dia o nmero de aplicaes de sistemas de computao onde disponibilidade e confiabilidade so exigidas em alto grau. Os usurios de sistemas de computao esto se tornando mais exigentes quanto a segurana e se mostram um pouco mais dispostos a enfrentar os custos adicionais das tcnicas de tolerncia a falhas.
rea de Aplicao Tempo real Telefonia Sistemas de transaes Servidores de rede Sistemas seguros Exemplos FTMP, SIFT, August 300, Space Shuttle AT&T ESS, Siemens EDS, Ericson AXE, Siemens SSP113 Tandem, Stratus (Olivetti CPS32 e IBM/88), VAXft, Teradata e Sequoia Sun Enterprise, Stratus, Compac, Cluster NT SIMIS

Tabela 9 - Exemplos por rea de aplicao Convm ressaltar que mesmo para as reas onde se dispe de sistemas tolerantes a falhas, esses no se apresentam prontos para a imediata utilizao. O desenvolvedor de software ou o usurio especializado desses sistemas deve sempre prover alguns recursos complementares para garantir tolerncia a falhas na sua aplicao. Alm disso, os sistemas comerciais geralmente s garantem tolerncia a falhas isoladas de hardware. Mecanismos contra falhas mltiplas e mesmo falhas de software devem ser supridas pelo desenvolvedor. O desenvolvedor deve, portanto, reconhecer exigncias quanto a confiabilidade e disponibilidade de uma determinada aplicao, saber escolher o sistema de menor custo que supra essas exigncias e ter condies de desenvolver os mecanismos

21

complementares de tolerncia a falhas para atingir a confiabilidade desejada. Naturalmente esse um desenvolvedor especialista, conhecedor de tcnicas de tolerncia a falhas e sua utilizao eficiente.

5 Concluso
O texto apresentou os conceitos bsicos de tolerncia a falhas e mostrou algumas reas de aplicao de computadores tolerantes a falhas. Praticamente todos os exemplos citados toleram erros provocados por falhas de hardware. entretanto fcil de imaginar que com a utilizao de componentes cada vez mais confiveis e sistemas de software cada vez mais complexos, erros que ocorram em sistemas de computao sejam devidos predominantemente a falhas de software. Essas falhas tanto podem estar localizadas no sistema operacional, nos programas aplicativos ou nos compiladores e interpretadores dos programas aplicativos. Falhas em software podem ser contornadas por tcnicas de tolerncia a falhas especficas, como diversidade, ou por tcnicas que evitam erros como verificao formal. impossvel prever qual dessas tcnicas prevalecer no futuro. interessante observar que em muitos sistemas deteco de erros provocados por falhas de hardware, mascaramento, recuperao e reconfigurao so comandados por software. Nesses sistemas essencial que esse software seja seguro, preferencialmente verificado quanto a correo. Profissionais de computao devem encarar seriamente os problemas ocasionados por falhas no tratadas nos sistemas informatizados. Tolerncia a falhas compreende muitas das tcnicas que permitem aumentar a qualidade de sistemas de computao. Apesar da tolerncia a falhas no garantir comportamento correto na presena de todo e qualquer tipo de falha e apesar das tcnicas empregadas envolverem algum grau de redundncia e, portanto, tornarem os sistemas maiores e mais caros, ela permite alcanar a confiabilidade e a disponibilidade desejadas para os sistemas computadorizados. Vrios desafios ainda devem ser vencidos, tolerncia a falhas no uma rea de pesquisa completamente dominada. Apesar de antiga uma rea onde muita aplicao, avaliao e popularizao se fazem necessrias.

6 Bibliografia
[AnLe81] ANDERSON, T.; LEE, P. A. Fault tolerance -principles and practice. Englewood Cliffs, Prentice-Hall, 1981. [Aviz98] AVIZIENIS, A. Infraestructure-based design of fault-tolerant systems. In: Proceedings of the IFIP International Workshop on Dependable Computing and its Applications. DCIA 98, Johannesburg, South Africa, January 12-14, 1998. p. 51-69.

[AvKe84] AVIZIENIS, A.; KELLY, J. P. Fault tolerance by design diversity concepts and experiments. Computer, New York, 17(8):67-80, Aug. 1984. [Bir96] BIRMAN, K. Building secure and reliable network applications, 1996

[ChAv78] CHEN, L.; AVIZIENIS, A. N-version programming: a fault tolerance approach to reliability of software operation. In: Annual International

22

Symposium on Fault-Tolerant Computing, 8, 1978. Proceedings. New York, IEEE, 1978. p. 3-9. [Crev56] CREVELING, C.J. Increasing the reliability of electronic equipment by the use of redundant circuits. Proceedings of the IRE. New York, 44(4):509515, abr. 1956. GRKE, W. Fehlertolerante Rechensysteme. Mnchen, Oldenburg Verlag, 1989. HOPKINS, A. L; SMITH, T. B.; LALA, J. H. FTMP - a highly realible fault-tolerant multiprocessor for aircraft. Procedings of the IEEE, New York, 66(10):1221-1239, Oct. 1978. JALOTE, P. Fault tolerance in distributed systems. Prentice Hall, Englewood Cliffs, New Jersey, 1994. JANSCH-PORTO, I. E. S; WEBER, T. S. Recuperao em Sistemas Distribudos. In: XVI Jornada de Atualizao em Informtica, XVII Congresso da SBC, Braslia, 2-8 agosto de 1997. anais. pp 263-310 JOHNSON, D. The Intel 432: a VLSI architecture for fault-tolerant computer systems. Computer, New York, 17(8):40-48, Aug. 1984. KATZMAN, J. A. A fault-tolerant computing system. In: Hawaii International Conference of System Sciences, 1978, Proceedings. p. 85-102. KNIGHT, J. C., LEVESON, N. G.; St.JEAN, L. D. A large scale experiment in n-version programming. In: Annual International Symposium on Fault-Tolerant Computing, 15, Ann Arbor, June 19-21, 1985. Proceedings. New York, IEEE, 1985. p. 135-139. LAPRIE, J. C. Dependable computing and fault-tolerance: concepts and terminology. In: Annual International Symposium on Fault Tolerant Computing, 15. Ann Arbor, jun. 19-21, 1985. Proceedings. New York, IEEE, 1985. p. 2-11. LAPRIE, J. C.; Dependability: von concepts to limits. In: Proceedings of the IFIP International Workshop on Dependable Computing and its Applications. DCIA 98, Johannesburg, South Africa, January 12-14, 1998. p. 108-126. LIU, T. S. The role of a maintenance processor for a general-purpose computer system. IEEE Transations on Computers. New York, c-33(6):507517. June 1984.

[Goer89] [HSL78]

[Jal94] [Jans97]

[John84] [Katz78] [KLJ85]

[Lapr85]

[Lapr98]

[Liu84]

[LyVa62] LYONS, R.E.; VANDERKULK, W. The use of triple-modular redundancy to improve computer reliability. IBM Journal of Research and Development. New York, 6(3): 200-209, abr. 1962. [Mul93] [Prad96] MULLENDE, S. Distributed systems. Addison-Wesley, ACM Press, New York, 1993. PRADHAN, D. K., Fault-Tolerant System Design. Prentice Hall, New Jersey, 1996.

23

[RSNG82] REILLY, J; SUTTON, A.; NASSER, R.; GRISCOM, R. Processor controller for the IBM 3081. IBM Journal of Research and Development, 26(1):22-29. Jan. 1982. [SiSw82] SIEWIOREK, D. P.; SWARZ, R. S. The Theory and Practice of Reliable System Design. Bedford, Digital, 1982. [Toy78] TOY, W. N. Fault-tolerant design of local ESS processors.Proceedings of the IEEE, New York, 66(10):1126-1145, Oct. 1978.

[VonN56] VON NEWMANN, J. Probabilistic logics and the synthesis of reliable organisms from unreliable components. In: Automata Studies, Shannon & McCarthy eds. Princeton Univ. Press, 1956. p. 43-98. [Web90] Weber, T.; Jansch-Prto, I.; Weber, R. Fundamentos de tolerncia a falhas. Vitria: SBC/UFES, 1990. (apostila preparada para o IX JAI - Jornada de Atualizao em Informtica, no X Congresso da Sociedade Brasileira de Computao).

[Wens78] WENSLEY, J. H. et al. SIFT: design and analysis of fault-tolerant computer for aircraft control. Proceedings of the IEEE, New York, 66(10):1240-1254, Oct. 1978. [Wens83] WENSLEY, J. H. Industrial-control system does things in threes for safety. Electronics, New York, 56(2):98-102. Jan. 1983. [WeWe89] WEBER, R. F.; WEBER, T. S. Um experimento prtico em programao diversitria. In: III Simpsio em Sistemas de Computadores Tolerantes a Falhas, SCTF, Rio de Janeiro, 20-22 set. Anais. Rio de Janeiro, 1989. p. 271-290.

24