Um roteiro para explorao dos conceitos bsicos

de tolerncia a falhas
Taisy Silva Weber1
Instituto de Informtica UFRGS
Curso de Especializao em Redes e Sistemas Distribudos
taisy@inf.ufrgs.br

Resumo
Em um ambiente distribudo suportado por infra-estrutura de rede de computadores,
supem-se que o sistema computacional opere apropriadamente, sem interrupo no seu
servio e sem perda de dados ou mensagens. No mundo ideal, sistemas computacionais
so totalmente confiveis e cem por cento disponveis. No mundo real, confiabilidade e
disponibilidade absolutas esto muito longe de serem alcanadas. A confiabilidade e a
disponibilidade de equipamentos e servios de computao no so conceitos abstratos
e absolutos, mas so atributos de um sistema que podem ser medidos quantitativamente.
Vrias tcnicas de projeto podem ser usadas para aumentar o valor dessas medidas, que
podem chegar prximas a cem por cento. Mesmo assim, sistemas totalmente infalveis
so impossveis, pois falhas so inevitveis. Mas usurios e desenvolvedores no devem
se conformar com equipamentos e servios de baixa qualidade, desde que estejam
dispostos a arcar com o custo do emprego de tcnicas de tolerncia a falhas.
Esse texto conduz o leitor a um viso geral da rea de tolerncia a falhas visando
motiv-lo para aprofundamentos e pesquisas posteriores. So explorados tanto aspectos
tericos como exemplos prticos. O texto no visa substituir um bom livro texto. Na
bibliografia recomendada no final do texto, referncias a tais livros podem ser
encontradas.

Palavras-chave: tolerncia a falhas, alta disponibilidade, confiabilidade, medidas,

arquiteturas de alta disponibilidade, clusters, sistemas distribudos, consenso,
comunicao confivel, replicao, recuperao, injeo de falhas.

Professora orientadora do PPGC, UFRGS, coordenadora da especializao em Redes e Sistemas

Distribudos, UFRGS, Coordenadora da comisso de Extenso, do Instituto de Informtica, Diretora
Administrativa e de Finanas da Sociedade Brasileira de Computao

ndice
1

Introduo................................................................................................................. 4
1.1 Mercado para produtos tolerantes a falhas ........................................................... 4
1.2 Sobre o texto......................................................................................................... 5
1.3 Defeitos em sistemas de computao ................................................................... 5
1.4 Desafios atuais...................................................................................................... 6
1.5 Tolerncia a falhas ou dependabilidade?.............................................................. 7
Conceitos clssicos ................................................................................................... 8
2.1 Falha, erro e defeito .............................................................................................. 8
2.2 Dependabilidade ................................................................................................. 10
2.3 Nmero de noves ................................................................................................ 13
2.4 Medidas relacionadas a tempo mdio de funcionamento................................... 13
Tcnicas para alcanar dependabilidade................................................................. 16
3.1 Tolerncia a falhas.............................................................................................. 16
3.2 Fases de aplicao das tcnicas de tolerncia a falhas ....................................... 17
3.3 Mascaramento de falhas ..................................................................................... 20
Redundncia ........................................................................................................... 21
4.1 Redundncia de informao ............................................................................... 21
4.2 Redundncia temporal ........................................................................................ 22
4.3 Redundncia de hardware................................................................................... 22
4.4 Redundncia de software.................................................................................... 26
Aplicaes de Sistemas Tolerantes a Falhas .......................................................... 29
5.1 reas de Aplicao............................................................................................. 29
5.2 Sistemas de tempo real ....................................................................................... 30
5.3 Sistemas digitais de telefonia ............................................................................. 30
5.4 Sistemas de transaes ....................................................................................... 31
5.5 Servidores de redes............................................................................................. 32
5.6 Sistemas seguros................................................................................................. 33
Arquiteturas de Sistemas Tolerantes a Falhas ........................................................ 34
6.1 Tolerncia a falhas em microprocessadores ....................................................... 34
6.2 Tolerncia a falhas em sistemas de grande porte ............................................... 36
6.3 Computadores de bordo...................................................................................... 37
6.4 Sistemas Comerciais Tolerantes a Falhas........................................................... 38
Clusters de alta disponibilidade.............................................................................. 41
7.1 Compartilhamento de recursos de armazenamento ............................................ 41
7.2 Exemplos de cluster de alta disponibilidade ...................................................... 42

Taisy Silva Weber

7.3 Disponibilidade em HA-clusters ........................................................................ 46

8 Tolerncia a Falhas em Sistemas Distribudos ....................................................... 48
8.1 Motivao para tolerncia a falhas em sistemas distribudos............................. 48
8.2 Classificao das tcnicas de tolerncia a falhas em camadas ........................... 49
8.3 Modelos de sistemas distribudos ....................................................................... 49
8.4 Falhas em sistemas distribudos ......................................................................... 50
8.5 Processadores Fail-stop e armazenamento estvel ............................................. 51
8.6 Consenso............................................................................................................. 51
8.7 Protocolos de difuso confivel.......................................................................... 52
8.8 Recuperao em sistemas distribudos ............................................................... 53
8.9 Gerenciamento e manipulao de grupos........................................................... 54
8.10 Replicao de dados ....................................................................................... 55
9 Validao de tcnicas de tolerncia a falhas .......................................................... 57
10 Concluso ............................................................................................................... 59
11 Bibliografia............................................................................................................. 61

Taisy Silva Weber

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, administradores de sistemas e usurios se vm s
voltas com atividades bastante criativas, mas nada gratificantes, de tentar recuperar
dados perdidos e de enfrentar equipamento fora do ar devido s mltiplas falhas a que
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 administrador de sistemas a implementar as mais simples, ou exigir dos
fornecedores e desenvolvedores de sistemas solues que as incorporem.
Entretanto, as tcnicas que toleram falhas tem um alto custo associado. Pode ser a
simples necessidade de backup dos dados, que consome espao de armazenamento e
tempo para realizar a cpia, ou a redundncia de equipamentos e espelhamento de
discos, que consome recursos de hardware sem contribuir para o aumento do
desempenho. O domnio da rea de tolerncia a falhas auxilia administradores e
desenvolvedores de sistemas a avaliar a relao custo benefcio para o seu caso
especfico e determinar qual a melhor tcnica para seu oramento.
Sistemas mais robustos em relao a falhas eram, at recentemente, preocupao apenas
de projetistas de sistemas crticos, como avies, sondas espaciais e controles industriais
de tempo real, e em certo grau tambm de projetistas de mainframes com exigncias de
alta disponibilidade. 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 conectado a uma rede deve
apresentar um mnimo de confiabilidade.
Conhecer os problemas potencialmente provocados por falhas no sistema, as solues
que existem para evitar falhas ou recuperar o sistema aps a sua ocorrncia, assim como
o custo associado a essas solues, torna-se imprescindvel a todos que pretendem
continuar usando computadores, desenvolvendo sistemas ou fornecendo um servio
computacional de qualidade aos seus clientes. Para desenvolvedores de software,
projetistas de hardware e administradores de rede, o domnio das tcnicas de tolerncia
a falhas torna-se essencial na seleo de tecnologias, na especificao de sistemas e na
incorporao de novas funcionalidades aos seus projetos.

1.1 Mercado para produtos tolerantes a falhas

Existe um mercado mundial para tolerncia a falhas que envolve grande soma de
recursos financeiros. Esse mercado engloba no apenas operaes crticas de tempo real
(como transportes, avinica, controle de processos em tempo real, comunicaes), mas

Taisy Silva Weber

tambm operaes comerciais de misso crtica (como as suportados por sistemas de

transaes e sistemas distribudos).
Empresas que dominavam o mercado mundial para aplicaes comerciais tolerantes a
falhas at a dcada de 80, Tandem e Stratus, produziam mainframes de altssimo custo
para organizaes bancrias e financeiras. A partir da dcada de 90, essas empresas, e
tambm SUN, Digital, IBM, Novell e Compac (que incorporou a Tandem) alm de
vrias outras, comearam a lanar solues de alta disponibilidade para servidores de
rede e clusters, geralmente de alto custo (como por exemplo a srie de servidores SUN
Enterprise). Uma famlia de microprocessadores muito popular, Intel 80x86, incorpora
desde o i486 uma gama de recursos para tolerncia a falhas, que, se bem utilizados,
poderiam aumentar consideravelmente a confiabilidade dos sistemas produzidos com
esses microprocessadores. Infelizmente, por razes associadas a custos e tambm
principalmente pela carncia de uma cultura em confiabilidade, os recursos desses
microprocessadores no so plenamente aproveitados.
Com a popularizao de aplicaes na Internet prevista uma grande demanda por
equipamentos de alta disponibilidade e software e servios que tolerem em maior ou
menor grau a inevitvel ocorrncia de falhas que assola sistemas computacionais.

1.2 Sobre o texto

O texto visa dar uma viso geral da rea, que bastante ampla. Foi escrito
especialmente para cursos de especializao e no visa cobrir em profundidade cada um
dos tpicos tratados.
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 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. Outras fontes de referncia importante so os anais de eventos da Sociedade
Brasileira de Computao especficos da rea, como o SCTF, Simpsio Brasileiro de
Tolerncia a Falhas, e do WTF, Workshop de Testes e Tolerncia a Falhas. Alm deles,
tambm nos simpsios SBRC e SBAC podem ser encontrados alguns artigos que tratam
de assuntos relacionados a Tolerncia a Falhas. Mais informaes sobre esses eventos
podem ser obtidas no site da SBC (www.sbc.org.br). Na arena internacional, o melhor
evento o DSN, Dependable Systems and Networks, que substituiu o FTCS desde
2000. Os artigos completos desses dois ltimos eventos podem ser obtidos em DVD
[IEEE01].

1.3 Defeitos em 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,

Taisy Silva Weber

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. Dos primeiros computadores a vlvula, que queimavam e
sobreaqueciam rotineiramente, eram extremamente sensveis umidade dos nossos
trpicos e se soltavam dos soquetes a qualquer trepidao, at a robustez dos notebooks
modernos, um acelerado caminho tecnolgico foi percorrido.
Entretanto, o software e os procedimentos de 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 foram ainda descobertos.
Alguns defeitos relatados na literatura [Lapr98] valem a pena ser mencionados: na
guerra do Golfo em fevereiro de 1991 foram noticiados vrios relatos de falhas em
msseis. 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. Vrias misses da
Nasa a Marte terminaram em fracasso total ou parcial. 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.4 Desafios atuais

Para tornar populares solues que nos garantam a confiana que depositamos em
sistemas de computao, vrios desafios devem ser vencidos:
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 no 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?
Como desenvolver computadores mveis e sistemas embarcados, garantindo
confiabilidade e segurana nesses dispositivos, e assegurando simultaneamente

Taisy Silva Weber

baixo consumo de potncia, sem recorrer a tcnicas usuais de replicao de

componentes que aumentam peso e volume?
Finalmente, como conciliar alta confiabilidade e alta disponibilidade com as
crescentes demandas por alto desempenho?
Todos esses desafios ainda permanecem sem uma soluo definitiva.

1.5 Tolerncia a falhas ou dependabilidade?

O termo tolerncia a falhas foi cunhado por Avizienis em 1967. Desde ento tem sido
amplamente utilizado pela comunidade acadmica para designar toda a rea de pesquisa
ocupada com o comportamento de sistemas computacionais sujeitos a ocorrncia de
falhas, sem ter entretanto logrado sucesso como designao popular. Na indstria o
termo nunca teve boa aceitao, sendo que desenvolvedores de sistemas de controle
preferem usar o termo sistemas redundantes para seus equipamentos. Na
comercializao de sistemas computacionais como mainframes e servidores de rede, o
termo usual alta disponibilidade, designando a principal qualidade desses sistemas.
Sistemas redundantes e sistemas de alta disponibilidade apresentam tcnicas comuns
mas alcanam resultados diferentes, uns visam alta confiabilidade e outros continuidade
de servio. Para englobar essas qualidades embaixo de um nico chapu,
freqentemente aparece o termo segurana de funcionamento. Com a popularidade do
termo segurana computacional, relacionado aos aspectos de segurana contra intrusos e
mal-intencionados e que engloba criptografia, autenticao e vrios tipos de proteo de
sistemas, o termo segurana de funcionamento relacionado a tolerncia a falhas caiu em
desuso.
O prprio termo tolerncia a falhas como designao de rea sofre vrias crticas, no
apenas no Brasil, mas tambm internacionalmente. A maior crtica a possibilidade de
entender o termo como uma propriedade absoluta. Nessa viso distorcida, um sistema
tolerante a falhas toleraria toda e qualquer falha em qualquer situao, o que realmente
uma promessa irrealizvel e pode conduzir a falsas expectativas entre usurios.
Aos poucos o termo dependabilidade vem substituindo tolerncia a falhas no meio
acadmico. Em 2000, o Fault Tolerant Computing Symposium, FTCS, foi rebatizado
Dependable Systems and Networks. Em 2003, o SCTF vai passar a se chamar LADC,
Latin America Dependable Computing.
Ser o fim de tolerncia a falhas? Entre ns, por enquanto, ainda no. Dependabilidade
um termo que soa estranho aos nossos ouvidos e no conseguimos encontrar ainda um
adjetivo que se ajuste ao termo. Mais detalhes sobre dependabilidade sero apresentados
no item 2.2.

Taisy Silva Weber

2 Conceitos clssicos
Sendo a computao uma tecnologia recente, muitos termos e conceitos no esto ainda
consolidados e nem so amplamente aceitos. Vrios grupos usam os mesmos termos
para conceitos distintos ou ento termos diferentes para designar a mesma propriedade
ou conceito.
Muitos autores nacionais ou estrangeiros tem se ocupado da nomenclatura e conceitos
bsicos da rea. No SCTF e no WTF, painis e discusses tem sido conduzidos tentando
uma nomenclatura comum no territrio nacional e at mesmo uma traduo homognea
dos termos usados. Como o grupo de pesquisadores est em expanso, a cada trabalho
de um novo autor novos termos conflitantes so introduzidos.
No tenho a pretenso de estabelecer meus termos e minhas tradues como padro da
rea. A minha inteno que o leitor entenda os conceitos relacionados aos termos e
consiga identificar esses conceitos em contextos diferentes, com termos diferentes. Os
conceitos e termos 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].

2.1 Falha, erro e defeito

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 um defeito. Finalmente
define-se falha ou falta (fault) como a causa fsica ou algortmica do erro.
Falhas so inevitveis. Componentes fsicos envelhecem e sofrem com interferncias
externas, sejam 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.
Defeitos so evitveis usando tcnicas de tolerncia a falhas.
Alguns autores nacionais traduzem as palavras inglesas failure como falha e fault como
falta. Para ser coerente com essa ltima traduo a rea deveria se chamar tolerncia a
faltas, pois failures no podem ser toleradas.
2.1.1

O modelo de 3 universos

Na Figura 1 mostrada uma simplificao, sugerida por Barry W. Johnson [Prad96], e

tambm 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.

Taisy Silva Weber

processamento
posterior pode levar a
defeito

universo da informao
universo fsico
falha

erro
universo do usurio

defeito
desvio da
especificao

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

Por exemplo: 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).
2.1.2

Latncia

Define-se latncia de falha como o perodo de tempo desde a ocorrncia da falha at a

manifestao do erro devido quela falha. Define-se latncia de erro como o perodo
de tempo desde a ocorrncia do erro at a manifestao do defeito devido aquele erro.
Baseando-se no modelo de 3 universos, o tempo total desde a ocorrncia da falha at o
aparecimento do defeito a soma da latncia de falhas e da latncia de erro.
2.1.3

Classificao de falhas

Existem vrias classificaes para falhas na literatura ([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, para definir uma falha considera-se ainda:
Natureza: falha de hardware, falha de software, de projeto, de operao, ...
Durao ou persistncia: permanente ou temporria (intermitente ou transitria)

Taisy Silva Weber

 Extenso: local a um mdulo, global

Valor: determinado ou indeterminado no tempo

Vem crescendo a ocorrncia daquelas falhas provocadas por interao humana

maliciosa, ou seja, por aquelas aes que visam propositadamente provocar danos aos
sistemas. Essas falhas e suas conseqncias so tratados por tcnicas de segurana
computacional (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 tolerantes a falhas

Tolerantes a falhas

Redes cliente-servidor
(no tolerantes a falhas)

MTTF: 6 a 12 semanas
Indisponibilidade aps defeito:
1 a 4 horas

MTTF: 21 anos
(Tandem)

Disponibilidade mdia:
98%

Defeitos:
hardware
software
comunicao/ambiente
operaes

Defeitos:
software
operaes
hardware
ambiente

Defeitos:
projeto
operaes
fsicos

50%
25%
15%
10%

65%
10%
8%
7%

60%
24%
16%

Tabela 1 - Causas usuais de defeitos em sistemas de computao

(MTTF - Mean time to failure)

2.2 Dependabilidade
O objetivo de tolerncia a falhas alcanar dependabilidade. 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.
Tolerncia a falhas e dependabilidade no so propriedades de um sistema a que se
possa atribuir diretamente valores numricos. Mas os todos atributos da
dependabilidade correspondem a medidas numricas.
Principais atributos de dependabilidade [Prad96] so confiabilidade, disponibilidade,
segurana de funcionamento (safety), segurana (security), mantenabilidade, testabilidade e comprometimento do desempenho (performability). Um resumo dos principais
atributos mostrado na Tabela 2.

Taisy Silva Weber

10

Atributo

Significado

Dependabilidade qualidade do servio fornecido por um dado sistema

(dependability)
Confiabilidade
(reliability)

capacidade de atender a especificao, dentro de condies

definidas, durante certo perodo de funcionamento e condicionado
a estar operacional no incio do perodo

Disponibilidade
(availability)

probabilidade do sistema estar operacional num instante de tempo

determinado; alternncia de perodos de funcionamento e reparo

Segurana
(safety)

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

Segurana
(security)

proteo contra falhas maliciosas, visando privacidade,

autenticidade, integridade e irrepudiabilidade dos dados
Tabela 2 Resumo dos atributos de dependabilidade

2.2.1

Confiabilidade

A confiabilidade R(t) a capacidade de atender a especificao, dentro de condies

definidas, durante certo perodo de funcionamento e condicionado a estar operacional
no incio do perodo.
A definio acima implica algumas condies essenciais, muitas vezes esquecidas:
especificao: sem uma especificao do sistema, no possvel determinar se o

sistema est operando conforme esperado ou no, quando mais formal e

completa a especificao, mais fcil estabelecer essa condio. No possvel
estabelecer se um sistema sem especificao confivel ou no.
condies definidas: as condies de funcionamento do sistema devem ser bem
definidas. Um exemplo simples so as condies ambientais de temperatura e
umidade. Outro exemplo so os dados ou estmulos de entrada que o sistema
deve processar.
perodo de funcionamento: o tempo de misso deve ser conhecido. O tempo de
misso de uma viagem espacial diferente do tempo de misso de um vo
comercial domstico. Um sistema pode ser altamente confivel para 12 horas de
operao e depois necessitar de um longo perodo de repouso e reparo.
estado operacional no incio do perodo: no possvel falar em confiabilidade
de sistemas que j partem operando com defeitos.
Confiabilidade a medida mais usada em sistemas crticos, ou seja nos seguintes tipos
de sistemas:
sistemas em que mesmo curtos perodos de operao incorreta so inaceitveis,
sistemas em que reparo impossvel.

Exemplos j mencionados de sistemas confiveis so aviao e explorao espacial.

Taisy Silva Weber

11

Confiabilidade uma medida de probabilidade, pois a ocorrncia de falhas um

fenmeno aleatrio. Confiabilidade no pode ser confundida com disponibilidade. Um
sistema pode ser de alta confiabilidade e de baixa disponibilidade. Um exemplo seria
um avio que precisa de reparos e manuteno nos intervalos de vo.
2.2.2

Disponibilidade

Assim como a confiabilidade, a disponibilidade uma medida de probabilidade.

Disponibilidade a probabilidade do sistema estar operacional num instante de tempo
determinado.
Disponibilidade o atributo mais usado em sistemas de misso crtica. Sistemas de
consulta de base de dados on-line, servidores de rede, servidores de pginas web, so
alguns exemplos de sistemas onde alta disponibilidade requerida.
Disponibilidade no pode ser confundida com confiabilidade. Um sistema pode ser
altamente disponvel mesmo apresentando perodos de inoperabilidade, quando est
sendo reparado, desde que esses perodos sejam curtos e no comprometam a qualidade
do servio (Figura 2). Disponibilidade est muito relacionada com o tempo de reparo do
sistema. Diminuir o tempo de reparo resulta em um aumento de disponibilidade.
tempo entre 2 defeitos
t0

funcionamento

funcionamento

funcionamento

reparo

reparo

Figura 2: Alternncia de perodos de funcionamento e reparo

Apesar de disponibilidade e confiabilidade representarem atributos e corresponderem a
medidas diferentes, usurios no geral gostariam de ter sistemas com as duas
caractersticas. Disponibilidade e confiabilidade no so excludentes, mas as tcnicas
para implementar uma e outra podem ser bem diferentes.
2.2.3

Segurana de funcionamento

Segurana (safety) a probabilidade do sistema ou estar operacional, e executar sua

funo corretamente, ou descontinuar suas funes de forma a no provocar dano a
outros sistemas ou pessoas que dele dependam.
Segurana a medida da capacidade do sistema de se comportar de forma livre de
falhas (fail-safe). Um exemplo seria um sistema de transporte ferrovirio onde os
controles de um trem providenciam sua desacelerao e parada automtica quando no
mais conseguirem garantir o seu funcionamento correto. Em um sistema fail-safe, ou a
sada correta ou o sistema levado a um estado seguro.

Taisy Silva Weber

12

2.2.4

Outros atributos

Outras atributos importantes de um sistema so: comprometimento do desempenho

(performability), mantenabilidade e testabilidade. Todas essas medidas so igualmente
representadas por uma probabilidade.
Comprometimento do desempenho (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, e por conseqncia menor o
tempo que o sistema no estar disponvel devido a reparos.

2.3 Nmero de noves

Com o interesse crescente do mercado de servidores por sistemas de alta
disponibilidade, como servidores de redes e servidores web, uma medida de
disponibilidade est se tornando popular. a medida do nmero de noves na expresso
de percentagem de tempo de disponibilidade. Assim um sistema de cinco noves possui
disponibilidade de 99,999%. Um sistema de cinco noves (com 99,999% de
disponibilidade) oferece um servios contnuos, exceto aproximadamente 5 minutos por
ano.
Da mesma forma, para representar probabilidades muito prximas de 1 na medida de
confiabilidade, com um grande nmero de 9 aps a vrgula, usual usar a notao 0,9i.
Assim por exemplo 0,9999999 representado por 0,97. Esses nmeros, e at maiores,
so tpicos de sistemas de controle na aviao, representando a probabilidade do sistema
operar corretamente durante o tempo de misso, ou seja, durante o tempo de vo.

2.4 Medidas relacionadas a tempo mdio de funcionamento

As medidas para avaliao de dependabilidade mais usadas na prtica so: taxa de
defeitos, MTTF, MTTR, MTBF. Todas essas medidas esto relacionadas a confiabilidade R(t). A Tabela 3 mostra uma definio informal dessas medidas.
Os fabricantes deveriam fornecer medidas de dependabilidade para os seus produtos,
tanto para os componentes eletrnicos, como para os sistemas de computao mais
complexos. Tais medidas so determinadas pelo fabricante estatisticamente, observando
o comportamento dos componentes e dispositivos fabricados.

Taisy Silva Weber

13

Medida

Significado

Taxa de defeitos - failure rate,

hazard function, hazard rate

nmero esperado de defeitos em um dado

perodo de tempo; assumido um valor
constante durante o tempo de vida til do
componente.

MTTF - mean time to failure

tempo esperado at a primeira ocorrncia de

defeito

MTTR - mean time to repair

tempo mdio para reparo do sistema

MTBF - mean time between failure

tempo mdio entre as defeitos do sistema

Tabela 3- Medidas de confiabilidade

A taxa de defeitos de um componente dada por defeitos por unidade de tempo e varia
com o tempo de vida do componente.
Uma representao usual para a taxa de defeitos de componentes de hardware dada
pela curva da banheira. Na Figura 3 podem se distinguir 3 fases:
mortalidade infantil: componentes fracos e mal fabricados
vida til: taxa de defeitos constante
envelhecimento: taxa de defeitos 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 defeitos
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.

taxa de
defeitos

fase de envelhecimento
perodo de vida til

mortalidade
infantil

taxa de defeitos
constante

tempo
Figura 3: Curva da banheira
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

Taisy Silva Weber

14

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.

Taisy Silva Weber

15

3 Tcnicas para alcanar dependabilidade

Para desenvolver um sistema com os atributos de dependabilidade desejados, um
conjunto de mtodos e tcnicas deve ser empregado. Esses mtodos e tcnicas so
classificados conforme a Tabela 4.
Tcnica

Funo

preveno de
falhas

impede a ocorrncia ou introduo de falhas. Envolve a seleo de

metodologias de projeto e de tecnologias adequadas para os seus
componentes.

tolerncia a
falhas

fornece o servio esperado mesmo na presena de falhas. Tcnicas

comuns: mascaramento de falhas, deteco de falhas, localizao,
confinamento, recuperao, reconfigurao, tratamento.

validao

remoo de falhas, verificao da presena de falhas.

previso de
falhas

estimativas sobre presena de falhas e estimativas sobre

conseqncias de falhas.
Tabela 4 - Tcnicas para alcanar dependabilidade

Na Tabela 4 pode ser observado que o chapu dependabilidade abriga vrias outras
tcnicas, alm de tolerncia a falhas. Todas tem em comum o fato de se preocuparem,
de uma forma ou de outra, com a ocorrncia inevitvel de falhas. Vrios autores
consideram que a intruso maliciosa em um sistema computacional seria um tipo de
falha e, portanto, as tcnicas de segurana computacional (security) poderiam ser
abrigadas no mesmo chapu. Essa a razo de vrios eventos acadmicos na rea de
dependabilidade aceitarem tambm trabalhos de segurana.

3.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. A 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 termo 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 e mais recentemente a sistemas de misso crtica.
As tcnicas de tolerncia a falhas so de duas classes disjuntas:

Taisy Silva Weber

16

 mascaramento ou
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.

3.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, e ser discutida em
detalhes no item 3.3.
Fases

Mecanismos
duplicao e comparao
deteco de erros
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
confinamento e
operaes primitivas auto encapsuladas
avaliao
isolamento de processos
regras do tipo tudo que no permitido proibido
hierarquia de processos
controle de recursos
recuperao de erros tcnicas de recuperao por retorno (backward error recovery)
tcnicas de recuperao por avano (forward error recovery)
tratamento da falha diagnstico
reparo
Tabela 5 - 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. Eu prefiro 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 nas fases de
deteco de erros e de localizao de falhas, como uma tcnica isolada conduzida
periodicamente para diminuir a latncia.

Taisy Silva Weber

17

3.2.1

A primeira fase: deteco de erro

A primeira fase de Anderson 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 5. 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.
Um exemplo de mecanismo de deteco o esquema de duplicao e comparao
(Figura 4). Duas peas idnticas de hardware realizam a mesma computao sobre os
mesmos dados de entrada e comparam os resultados na sada. Havendo desacordo
assinalado erro.
2 mdulos idnticos de hardware
resultado

erro
COMPARADOR

ponto crtico de falha

(single point of failure)
comparador em software
ou hardware ?

Figura 4: Duplicao e comparao

3.2.2

A segunda fase: confinamento

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.
3.2.3

A terceira fase: recuperao

A recuperao de erros ocorre aps a deteco e envolve a troca do estado atual

incorreto para um estado livre de falhas.

Taisy Silva Weber

18

Tcnica

Definio

Caractersticas

forward
error
recovery

conduo a novo estado

eficiente, mas danos especfica a cada
ainda no ocorrido desde a devem ser previstos sistema
ltima manifestao de erro acuradamente

backward conduo a estado anterior

error
recovery

alto custo, mas de

aplicao genrica

Implementao

pontos de recuperao
(checkpoints), pistas de
auditoria, ...

Tabela 6 - Tcnicas de recuperao

A recuperao pode ser de duas formas (Tabela 6): tcnicas de recuperao por retorno
(backward error recovery) e tcnicas de recuperao por avano (forward error
recovery). Os dois tipos podem ser visualizados na Figura 5.
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 outros processos, que receberam suas mensagens, 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.
ponto de
recuperao
P

falha
rollback

novo estado

falha
avano

Figura 5: Recuperao por retorno e por avano

3.2.4

A quarta fase: tratamento

A ltima fase, tratamento de falhas, consiste em:

Taisy Silva Weber

19

 localizar a origem do erro (falha),

localizar a falha de forma precisa,
reparar a falha,
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 e rpida
(aplicada sobre um mdulo ou subsistema) e localizao fina, mais demorada, onde o
componente falho determinado. Para os dois tipos de localizao usado diagnstico.
O diagnstico um teste com comparao dos resultados gerados com os resultados
previstos. Pode ser conduzido no sistema de forma manual ou automtica:
diagnstico manual - executado por um operador local ou remoto,
diagnstico automtico - executado pelos componentes livres de falha do

sistema.
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
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.

3.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 7
lista mecanismos usuais para implementao de mascaramento de falhas. Alguns desses
mecanismos sero vistos em detalhes no item 4, que trata de redundncia.
Mecanismo

Aplicado a:

replicao de componentes

qualquer componente de hardware

ECC (cdigo de correo de erros)

informao transmitida ou armazenada

diversidade, programao n-verses

especificao, projetos, programas

blocos de recuperao

software

Tabela 7 - Mecanismos para mascarar falhas

Taisy Silva Weber

20

4 Redundncia
Redundncia a palavra mgica em tolerncia a falhas. Redundncia para aumento de
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.
A aplicao de redundncia para implementar tcnicas de tolerncia a falhas pode
aparecer de vrias formas:
redundncia de informao
redundncia temporal
redundncia de hardware
redundncia de software

Essas tcnicas de redundncia so apresentadas em mais detalhes nas prximas sees.

Todas essas formas de redundncia, de hardware, de software, temporal e 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 pode servir para deteco de falhas como para mascaramento de
falhas. O grau de redundncia em cada caso diferente. Para mascarar falhas so
necessrios mais componentes do que para detectar falhas. Por exemplo, para detectar
falhas em um microprocessador, muitas vezes usado outro microprocessador idntico,
sincronizado ao primeiro, alm de um comparador de sinais na sada de ambos
(duplicao e comparao). Qualquer diferena na comparao indica que o par de
microprocessadores est em desacordo, e que portanto um dos dois est danificado (ou
sofreu uma falha temporria). Entretanto est falha no pode ser mascarada. O resultado
da comparao no indica quais as sadas so as corretas.

4.1 Redundncia de informao

Na redundncia de informao, bits ou sinais extras so armazenados ou transmitidos
junto ao dado, sem que contenham qualquer informao til. Esses bits ou sinais extras
servem apenas para deteco de erros ou mascaramento de falhas.
Exemplos clssicos so cdigos de paridade, onde para cada n bits so armazenados
n+1 bits. O bit extra indica apenas se o nmero de bits com valor 1 nos restantes n bits
par (ou mpar, dependendo do tipo de paridade usada). Bits de paridade servem para
deteco de falhas simples, ou seja aquelas falhas que afetam apenas um bit de uma
palavra. Outros exemplos de cdigos usados para deteco de erros so checksums,
cdigos de duplicao, cdigos cclicos.

Taisy Silva Weber

21

Mascaramento usando redundncia de informao provida por cdigos de correo de

erros, como ECC (error correction code). Cdigos de correo de erros esto sendo
exaustivamente usados em memrias e em transferncia entre memrias e
processadores. Exemplos de ECC so os cdigos de Hamming, uma combinao de bits
de paridade que permite tanto deteco como correo.
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.

4.2 Redundncia temporal

Redundncia temporal repete a computao no tempo. Evita custo de hardware
adicional, aumentando o tempo necessrio para realizar uma computao. usada em
sistemas onde o tempo no crtico, ou onde o processador trabalha com ociosidade.
Aplicaes usuais da redundncia temporal:
deteco de falhas transitrias: 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 sempre
iguais.
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, a linha vai
transferir sempre zero.

4.3 Redundncia de hardware

Redundncia de hardware (Tabela 8) est baseada na replicao de componentes fsicos.
Redundncia de hardware

Tcnicas

Vantagens

redundncia passiva ou
esttica

mascaramento de
falhas

no requer ao do sistema, no
indica falha

redundncia ativa ou
dinmica

deteco, localizao substituio de mdulos, usada

e recuperao
em aplicaes de longa vida

redundncia hbrida

combinao de ativa
e passiva

usada para garantir mascaramento e longa vida; geralmente de alto custo

Tabela 8 - Redundncia de hardware

Os 3 tipos bsicos de redundncia de hardware so apresentados nos prximos itens.

Taisy Silva Weber

22

4.3.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
determinado por votao. Exemplos so TMR (triple modular redundancy) e NMR
(redundncia modular com n mdulos).
TMR, redundncia modular tripla, uma das tcnicas mais conhecidas de tolerncia a
falhas. TMR mascara falhas em um componente de hardware triplicando o componente
e votando entre as sadas para determinao do resultado (Figura 6). A votao pode ser
por maioria (2 em 1) ou votao por seleo do valor mdio [LyVa62].
O votador realiza uma funo simples, cuja correo fcil de verificar. interessante
observar que o votador no tem a funo de determinar qual o mdulo de hardware
discorda da maioria. Se essa 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.
ponto crtico de falha
(single point of failure )

3 mdulos de
hardware

resultado

VOTADOR

votador em software
ou hardware ?

por maioria ou
por valor mdio

Figura 6: TMR
Solues para contornar a fragilidade do votador so:
Construir o votador com componentes de alta confiabilidade.
Triplicar o votador.
Realizar a votao por software.

A Figura 7 mostra um esquema com votador triplicado. Os 3 resultados gerados podem,

nesse caso, ser levados aos prximos 3 mdulos de hardware do sistema.

Taisy Silva Weber

23

Deve ser observado que a redundncia aumenta o nmero de componentes do sistema.

Quando maior o nmero de componentes, maior a possibilidade de falha.

VOTADOR

resultados
VOTADOR

VOTADOR

3 mdulos de hardware
votador triplicado

Figura 7: TMR com votador triplicado

TMR apresenta uma confiabilidade maior que um sistema de um nico componente at
a ocorrncia da primeira falha permanente (Figura 8). 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.
R(t)

TMR

redundncia aumenta nmero de

componentes do sistema

no redundante

durao da misso
Figura 8: Confiabilidade de TMR
TMR ideal ento para perodos no muito longos de misso. Suporta uma falha
permanente apenas e ideal para falhas temporrias, uma de cada vez.

Taisy Silva Weber

24

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.
4.3.2

Redundncia dinmica

Na redundncia dinmica ou ativa, tolerncia a falhas provida pelo emprego das

tcnicas de deteco, localizao e recuperao (Figura 9). A redundncia empregada
neste caso no prov mascaramento.
testes e diagnsticos

localizao

deteco

duplicao e
comparao

reconfigurao

hot standby & cold

standby
Figura 9: Redundncia dinmica ou ativa

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. Geralmente prefervel defeitos
temporrios do que suportar o custo de grande quantidade de redundncia necessria
para o mascaramento de falhas.

operao normal

operao degradada

ocorrncia de falha

ocorrncia de erro

sistema com defeito

deteco e localizao
de falha

reconfigurao e
recuperao

Figura 10: Estados de um sistema com redundncia dinmica

Taisy Silva Weber

25

Os estados de um sistema com redundncia dinmica podem ser representado conforme

a Figura 10.
Um exemplo de implementao de redundncia dinmica atravs de mdulos estepe
(standby sparing). Mdulos estepe podem ser operados de duas formas conforme
Tabela 9.
Operao de mdulos estepe

Comentrios

alimentados (hot standby)

Mdulo estepe conectado eletricamente ao

sistema. Minimiza a descontinuidade do
processamento durante o chaveamento entre os
mdulos.

no alimentados (cold standby)

Mdulo estepe s comea a operar quando

conectado. Aumenta a vida til dos mdulos
estepe.

Tabela 9 - Exemplo de redundncia dinmica

4.4 Redundncia de software

A simples replicao de componentes idnticos uma estratgia de deteco e
mascaramento de erros 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 em tempos diferentes. Erros de
programas idnticos vo se apresentar, com grande probabilidade, de forma idntica
para os mesmos dados de entrada.
Existem outras formas de aplicar redundncia em software para deteco e
mascaramento, que no envolver cpias idnticas de software. Exemplos dessas outras
formas de redundncia em software so:
diversidade (ou programao n-verses)
blocos de recuperao
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.
4.4.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 11).

Taisy Silva Weber

26

verso 1
verso 2

verso n

resultado
VOTADOR

erros devem se manifestar de

forma diferente nas verses

Figura 11: 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.
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 usando
diversidade de metodologias e equipes, e de programao em n-verses, quando se
restringe implementao.
Diversidade 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
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

Taisy Silva Weber

27

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].
4.4.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 12). 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

verso secundria n-1

chave
n para 1

teste de
aceitao

programas so executados e testados um a um

at o primeiro passar no teste de aceitao

Figura 12: blocos de recuperao

Taisy Silva Weber

28

5 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
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.

5.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

aplicaes seguras de tempo real como transportes urbanos;
aplicaes em sistemas de tempo real de longo perodo de durao sem
manuteno, como em viagens espaciais, satlites e sondas;
aplicaes tcnicas como telefonia e telecomunicaes;
aplicaes comerciais de alta disponibilidade como sistemas de transao e
servidores de redes.

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.

Taisy Silva Weber

29

5.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:
Disponibilidade de apenas um curto intervalo de tempo para reconhecimento de

erros, de forma a no prejudicar o processamento em tempo real;

Impossibilidade de emprego de recuperao por retorno, uma vez que eventos
passados no so reproduzveis em sistemas de tempo real;
Exigncia de redundncia esttica para garantir a continuidade do
processamento em tempo real em caso de falha de um componente;
Comportamento livre de falhas (fail-safe), ou seja, em caso de ocorrncia de
uma falha que no possa ser mascarada, 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. O sistema de computao de bordo do Space
Shuttle um exemplo de sistema tempo real tolerante a falhas inspirado no projeto do
SIFT.

5.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;
Tratamento automtico de erros por reconfigurao do sistema;
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 (duplicao e
comparao), 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 - Electronic Switching System
[Toy78], da AT&T 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 e comparao.

Taisy Silva Weber

30

Outros exemplos de computadores para telefonia so os sistemas Siemens e, como os

demais exemplos citados, empregam exaustivamente duplicao de elementos.

5.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
em mquinas clientes. Exemplos so bancos de dados para aplicaes financeiras,
bancrias, 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;
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;

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 e sinaliza o erro, 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). Tandem implementava tolerncia a falhas com
processos primrios e processos backups, com superviso de seu sistema operacional
proprietrio. Stratus, por implementar tolerncia a falhas em hardware para deteco
(duplicao e comparao) e assim tornar os mecanismos transparentes s aplicaes,
acabou por suplantar a Tandem como lder no mercado.
Outros exemplos antigos 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).
Tandem, Stratus, Sequoia e outros fornecedores especializados em computadores
tolerantes a falhas acabaram saindo do mercado, se associaram a outras empresas de
maior porte e partir para desenvolver solues para nichos especficos de mercado. As

Taisy Silva Weber

31

arquiteturas comuns na dcada de 80 e incio de 90 passaram a figurar como exemplos

interessantes de solues de alta disponibilidade.

5.5 Servidores de redes

Redes so formadas por estaes de trabalho clientes e por servidores de rede. todas as
mquinas que formam uma rede se comunicam por trocas de mensagens. Em uma rede
local, o servidor responsvel por servios de suporte e controle da rede como
armazenamento e distribuio de dados e arquivos, gerenciamento e impresso de
documentos, gerenciamento de usurios, e tambm conexo a outras redes, alm de
vrias outras funes.
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 seus inmeros terminais. notvel sua aceitao tambm em
automao industrial. fcil perceber que a queda de um servidor pode comprometer a
produtividade de toda uma empresa, principalmente se esse servidor for o nico
disponvel ou se estiver executando servios vitais.
Requisitos quanto a tolerncia a falhas para aplicaes nessa rea so semelhantes aos
requisitos para sistemas de transao:
Garantia de integridade e redundncia de dados;
Alta disponibilidade do servidor para prover continuidade de servios na rede;
Tratamento automtico de erros de hardware e no servio da rede;
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.
Caracterstica

Descrio

Reconfigurao
automtica

o sistema reinicia imediatamente aps um defeito, desabilitando automaticamente o componente danificado. Envolve testes de componentes a cada vez
que o equipamento ligado ou quando gerada uma interrupo externa.

Fontes de energia e
ventilao redundantes

defeito em um desses componentes no interrompe a operao do sistema.

ECC para garantir

integridade dos dados

ECC usado em todos os caminhos de dados. Adicionalmente, paridade usada

nos endereos e linhas de controle do barramento e tambm nas caches.

Monitoramento
ambiental

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.

Ferramentas de
monitoramento
avanadas

registradores e contadores so usados para monitorar a atividade do sistema e

fornecer co de guarda (watchdog) em hardware. Os registradores so
acessados por software para obter dados de desempenho e para manuteno.

Ferramentas de
diagnstico online

realizam testes e registram os resultados obtidos. Os testes so realizados em

componentes (processadores, memria, I/O,), e no sistema como um todo

Troca de componentes
com o sistema em
operao

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 normal.

Tabela 10- Caractersticas da srie Sun Enterprise

Taisy Silva Weber

32

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), HP, Dell 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 10.

5.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
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:
Existncia de um estado seguro e facilidade de alcan-lo em caso de erro;
Rapidez no reconhecimento de erros;
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.

Taisy Silva Weber

33

6 Arquiteturas de Sistemas Tolerantes a Falhas

interessante que um sistema de computao seja suprido das tcnicas de tolerncia a
falhas adequadas para garantir a confiabilidade desejada, sem que as aplicaes tomem
conhecimento das tcnicas empregadas. A tolerncia a falhas de um sistema de
computao deveria idealmente estar suportada pelos nveis de hardware e software de
abstrao menor do que o nvel ocupado pelas aplicaes. Naturalmente essa
caracterstica no suprida por todos sistemas. Geralmente um especialista deve se
ocupar do planejamento de certas tarefas complementares, como por exemplo
estabelecimento de pontos de recuperao ou elaborao de rotinas diversitrias.
Um nvel adequado para suprir tolerncia a falhas a arquitetura do sistema de
computao. A arquitetura representa os componentes de hardware de um sistema
(como processadores, memrias, controladores, interfaces) e suas interconexes (como
barramentos e linhas seriais e paralelas de comunicao).
Recursos de tolerncia a falhas implementados na arquitetura para deteco de erros,
diagnstico, recuperao e reconfigurao so mais eficazes do que os implementados
exclusivamente nos nveis de aplicao e de sistema operacional, sem o suporte dos
nveis inferiores. A seguir so mostrados, como ilustrao, exemplos de arquiteturas
para sistemas tolerantes a falhas.

6.1 Tolerncia a falhas em microprocessadores

Microprocessadores formam a base de computadores pessoais, estaes de trabalho e
servidores de rede. Como foram inicialmente desenvolvidos aplicaes no crticas, os
microprocessadores mais populares recentemente comearam a apresentar alguns
mecanismos intrnsecos para o suporte de tcnicas de tolerncia a falhas.
grande e crescente o nmero de equipamentos nas reas de controle de processos
industriais, controle de trfego e instrumentao que usam microprocessadores
convencionais devido principalmente ao baixo custo, alto desempenho e capacidade de
processamento que esses componentes apresentam. Esses equipamentos e suas
aplicaes exigem um alto grau de dependabilidade. Naturalmente, desenvolvendo
hardware adicional como votadores e comparadores, microprocessadores
convencionais, mesmo sem recursos intrnsecos para suporte a tolerncia a falhas,
podem ser aproveitados para construir sistemas com falhas mascaradas ou com deteco
de falhas por duplicao e comparao.
Uma melhor soluo em termos de custo pode ser alcanada, entretanto, se suporte para
deteco e recuperao for suprida diretamente pelo microprocessador, sem necessidade
de hardware adicional. Um exemplo clssico de microprocessador com essa
caracterstica o antigo e j descontinuado iAPX432 da Intel [John84]. O suporte a
tolerncia a falhas implementado por esse processador no est relacionado s suas
caractersticas especficas (como conjunto de instrues, modos de endereamento e
registradores internos) e pode ser implementado em qualquer sistema digital integrado
com apenas um pequeno acrscimo na rea de silcio ocupada. Atualmente todos

Taisy Silva Weber

34

microprocessadores Pentium apresentam recursos derivados dessa primeira experincia

da Intel.
6.1.1

Mestre e verificador

O para mestre-verificador implementa o esquema de deteco de falhas por duplicao e

comparao, com o circuito comparador interno ao chip. Basicamente um
microprocessador pode ser configurado como mestre ou verificador (Figura 13). Um
mestre pode operar sozinho ou ligado a um verificador. Um verificador sempre deve
estar ligado a um mestre.
EN TR A D A

M ESTR E

VER IFIC AD O R
erro

SA ID A

Figura 13 - Configurao mestre-verificador

Um chip configurado como verificador tem seus pinos de sada revertidos para entrada.
Os pinos revertidos recebem sinais diretamente das sadas correspondentes do chip
mestre. As entradas originais dos dois chips, mestre e verificador, esto ligadas em curto
circuito. Internamente ao verificador, os sinais gerados como sada so comparados aos
sinais recebidos pelos pinos revertidos. Ocorrendo qualquer discrepncia na
comparao, o verificador sinaliza erro.
Entrada

Unidade
funcional

Controle
de reverso

Entrada/sada
(bidirecional)

c
o
m
p
a
r
a
d
o
r

Sinal
de erro

Figura 14: Unidade bsica para redundncia em microprocessadores

O par mestre-verificador permite facilmente deteco de erro. Com apenas essa
redundncia simples, o tratamento do erro no possvel por hardware. Usando uma
maior redundncia, por exemplo quatro chips, ligados dois a dois, tanto deteco
quando reconfigurao so possveis. Essa arquitetura quadruplicada apresenta um par
mestre-verificador primrio e outro par estepe. Os dois pares so ativos, mas apenas o

Taisy Silva Weber

35

par primrio fornece resultados ao sistema. Quando o verificador do par ativo detecta
um erro, chaveia-se para o par estepe, que passa a partir desse momento a operar
sozinho. Redundncia qudrupla degrada, nesse caso, para duplex, mas o funcionamento do sistema garantido sem queda de desempenho.
A redundncia usada aqui independente da funo especfica realizada pelo chip e
pode ser implementada em qualquer circuito digital. O chip resultante tem sua rea em
silcio aumentada em funo do comparador, das chaves bidirecionais para todos os
pinos de sada, do sinal de controle adicional necessrio para configurar o chip como
mestre ou verificador e do sinal de erro gerado no comparador (Figura 14). Todos os
circuitos construdos usando essa tcnica devem ser usados aos pares para deteco de
erros.
6.1.2

Tolerncia a falhas nos processadores Pentium

No microprocessador Intel 486 foi usada verificao de paridade para as transferncias

internas de dados entre caches e unidades de execuo. J no Pentium, adicionalmente
paridade nas caches, a TLB e a memria de microcdigo tambm so verificadas
quando paridade. No Pentium foram introduzidos recursos adicionais para verificao
de excees suportada por hardware (machine check exception). Tambm o esquema de
mestre-verificador (usado inicialmente no iapx432) com dois chips voltou a ser adotado
pela Intel a partir do Pentium.
O Pentium Pro mantm todas as tcnicas do Pentium e adicionalmente:
paridade nos bytes de dados substituda por 8 bits de ECC
2 bits de paridade para barramento de endereo associado a tcnicas de retry
bits de paridade para sinais de controle

No Pentium Pro verificao de excees conduzida pela MCA (machine check

architecture) que adiciona 3 registradores de controle e 5 bancos de 4 registradores de
erro aos recursos do microprocessador.

6.2 Tolerncia a falhas em sistemas de grande porte

Sistemas de grande porte para aplicaes universais (mainframes) apresentam
arquitetura composta de vrias unidades processadoras de alto desempenho, uma
memria comum de grande capacidade, alm de canais que permitem a ligao a uma
grande quantidade e variedade de perifricos. Apesar das aplicaes de mainframes no
serem geralmente crticas, os requisitos de disponibilidade impostos a esses sistemas
tem crescido fortemente nos ltimos anos.
Os vrios processadores de um mainframe, por serem de alto desempenho e velocidade,
so tambm de alto custo, o que impede a aplicao de redundncia pura e simples (ou
seja, a mera replicao de componentes) como tcnica para aumentar a disponibilidade.
A soluo mais comum, usada pelos fabricantes para aumentar a disponibilidade,
incluir um processador auxiliar com funes de console e manuteno. Esse processador

Taisy Silva Weber

36

de manuteno [Liu84], de pequeno porte e autnomo, operando independentemente

do mainframe, mas ligado diretamente a ele para poder supervision-lo.
Um processador de manuteno deve ter capacidade de autoteste e ser construdo com
componentes confiveis. No deve interferir no processamento normal do computador.
A existncia desse processador no dispensa o uso de outras tcnicas de tolerncia a
falhas, como cdigos de correo e deteco de erros. Tais cdigos permitem recuperar
erros transitrios de alta incidncia a baixo custo, sem necessidade de interveno do
processador de manuteno.
Tolerncia a falhas suprida pelas funes de superviso, diagnstico e recuperao.
Supervisionando continuamente o sistema, situaes de erro podem ser imediatamente
detectadas. Na deteco de um erro, o processador de manuteno atua da seguinte
maneira:
foi detectado um erro transitrio: o processo em erro interrompido e, to rpido

quanto possvel, recuperado para um estado livre de erros. O sistema

operacional recebe ento indicao de reiniciar o processo recuperado;
foi detectado um erro permanente: localizado o componente danificado e
procura-se uma configurao que garanta a operao normal. Pode acontecer:
reconfigurao possvel, mesmo com desempenho degradado. Por exemplo, se um processador falhar, o processo alocado para outro processador;
reconfigurao no possvel; o processador de manuteno diagnostica a
falha, facilitando o posterior reparo do sistema.
O processador de manuteno ligado a uma central de manuteno atravs de rede.
Assim ele pode ser suprido de programas de diagnstico sofisticados e atualizados
quando necessrio. Pode tambm avisar imediatamente o pessoal de manuteno da
necessidade de trocar placas ou componentes especficos.
Desde que seja garantida alta confiabilidade para o processador de manuteno, ele
representa uma soluo eficaz e de baixo custo para tornar computadores de grande
porte mais disponveis, diminuindo o tempo de reparo do sistema. Um exemplo de sua
aplicao pode ser encontrado nos computadores IBM de grande porte [RSNG82] e em
quase todos os computadores de grande porte atuais.

6.3 Computadores de bordo

Na aviao exigncias quanto a confiabilidade so extremamente altas, uma vez que
vidas humanas esto em jogo em situaes onde impossvel interrupo do sistema
para reparos. Computadores de bordo tem por funo controlar ativamente a aeronave
em uma situao cuja normalidade caracterizada por instabilidade. Correes para
manter estabilidade de vo devem ser feitas continuamente, no instante preciso em que
so necessrias (ou seja, em tempo real) e com tempo de atuao curto.
Para computadores de bordo exigida uma taxa de falhas da ordem de 10-9 falhas por
hora para um vo de 10 horas. Alm disso deve ser considerado:
reparo possvel apenas durante os intervalos de vo, e no mais freqen-

temente do que a cada centena de horas de vo;

Taisy Silva Weber

37

 no admissvel qualquer tipo de interrupo no funcionamento do sistema.

Essas exigncias extremas quanto confiabilidade s podem ser alcanadas atravs da

aplicao em larga escala de tolerncia a falhas. Como exemplo podem ser citados dois
computadores de bordo desenvolvidos na dcada de 70 sob encomenda da NASA:
FTMP (Fault Tolerant Multi-Processor) e SIFT (Software Implemented Fault
Tolerance). Os dois processadores foram projetados tendo por base a mesma especificao.
Tanto FTMP [HSL78] como SIFT [Wens78] so baseados em redundncia modular
tripla (TMR). Entretanto, nos dois sistemas o votador implementado de forma diversa.
No FTMP o votador um elemento de hardware, todos os processadores so
sincronizados e o relgio central tolerante a falhas. No SIFT votao realizada por
software, os processadores so assncronos, sem relgio central, de tal forma que
tambm o sincronismo para o fornecimento de resultados para votao deve ser
garantida por software.
Os dois sistemas, FTMP e SIFT, apresentam alta confiabilidade para aplicaes em
tempo real. FTMP apresenta entretanto um esquema de votao mais eficiente e mais
rpido, pois realizado em hardware. No FTMP tolerncia a falhas no visvel a partir
da aplicao, ao contrrio do que ocorre no sistema SIFT onde a votao realizada por
software.
Baseado no SIFT foi desenvolvido o computador de bordo para o Space Shuttle
[Prad96], o que de certa forma atesta que a flexibilidade obtida pela votao em
software supera em vantagem a velocidade obtida pela votao em hardware.

6.4 Sistemas Comerciais Tolerantes a Falhas

So muito citados na literatura dois exemplos de computadores de grande porte
especialmente desenvolvidos para aplicaes comerciais tolerantes a falhas: Tandem
[Katz78] e Stratus [Hend83]. Esses dois sistemas foram os mais populares para
aplicaes em sistemas comerciais de transaes [Serl84] durante a dcada de 80 at
meados da dcada de 90. Tandem e Stratus so tambm dois bons exemplos de
mecanismos de tolerncia a falhas implementados em software (Tandem) e em
hardware (Stratus).
Atualmente a rea de computadores tolerantes a falhas de grande porte praticamente
inexpressiva em termos de novidades e negcios. Todos os grandes fabricantes
comercializam solues ditas de alta disponibilidade ou mesmo tolerantes a falhas.
Tandem, incorporada a Compac, e a Stratus continuam aplicando suas tcnicas
proprietrias na rea de servidores de redes.
6.4.1

Tandem

Um sistema composto vrios mdulos computacionais interligados por um barramento

duplicado. Cada mdulo formado por um processador, uma memria local, um canal
de entrada e sada e fonte de alimentao. O sistema dispe ainda de uma srie de

Taisy Silva Weber

38

controladores de dispositivos de entrada e sada. Os controladores podem aparecer

duplicados. Cada um deles est conectado a dois canais de E/S.
Complementando redundncia em hardware, o sistema possui tambm redundncia
dinmica em software. O sistema operacional formado por um kernel e um grande
nmero de processos, em especial processos de superviso para cada um dos
processadores. Tanto para processos do sistema como para processos do usurio, o
sistema operacional permite a criao de pares. Um par formado por um processo
primrio ativo e um processo substituto passivo. O processo primrio envia pontos de
recuperao ao processo substituto.
Diagnstico de erros se processa da seguinte forma:
erros em um mdulo so detectados em outros mdulos processadores;
a cada segundo, o processo supervisor de um mdulo envia sinal de vida a todos

os outros mdulos no sistema;

a cada dois segundos, o processo supervisor verifica se recebeu sinal de vida de
cada um dos outros mdulos. Se faltar um sinal, o processo entende que o
mdulo correspondente falhou.
Alm desse controle mtuo, para cada operao de entrada e sada realizado controle
de time-out. Em caso de falha, o processo de entrada e sada substituto entra em
operao.
Um vez diagnosticada a falha em um mdulo, todos os processos substitutos
relacionados aos processos primrios que estavam sendo executados no mdulo so
rolados para o ltimo ponto de recuperao (recuperao por retorno) e ativados,
tornando-se ento processos primrios. O sistema reconfigurado em funo dos novos
processos primrios. To logo o mdulo faltoso seja reparado, os novos processos
primrios criam seus processos substitutos nesse mdulo. Em caso de falha de um canal
de entrada e sada, o processo substituto correspondente rolado e ativado, enquanto o
processo primrio desativado passando a ser substituto do primeiro.
6.4.2

Stratus Continuous Processing

Um sistema tpico pode ser composto de 1 a 32 mdulos, interconectados atravs de

uma rede local. Os elementos em um mdulo so interligados por um barramento
interno. Os mdulos do sistema Stratus no esto disponveis para redundncia
dinmica.
Cada mdulo composto de dois grupos idnticos de componentes de hardware e um
circuito lgico para comparao dos resultados de todas as operaes que so realizadas
em paralelo (duplicao e comparao). Todos os mdulos podem aparecer por sua vez
duplicados. Essa duplicao entretanto transparente ao usurio e s aplicaes.
Tanto o sistema operacional como os programas de aplicao apresentam apenas alguns
recursos bvios de tolerncia a falhas, uma vez que o sistema foi especificado para
prover tolerncia a falhas por hardware.
Cada mdulo do sistema compara os resultados fornecidos pelos elementos duplicados.
Quando a comparao indica erro, nenhum resultado fornecido como sada, o mdulo

Taisy Silva Weber

39

 desconectado do sistema, sendo ento enviado um sinal de erro a um programa de

manuteno. Esse programa providencia testes no mdulo para determinar se a falha
permanente ou transitria. Em ambos os casos, registrado o problema e indicado o
erro em um terminal de superviso. Se o mdulo faltoso aparecia duplicado no sistema,
sua falha permanece invisvel aplicao, pois a unidade redundante garante a
continuidade do processamento.
Caso o programa de manuteno tenha detectado uma falha transitria, o mdulo que
sofreu a falha ressincronizado com a unidade redundante correspondente e entra
imediatamente em operao. Caso seja uma falha permanente, o mdulo substitudo
manualmente sem interromper o processamento normal.

Taisy Silva Weber

40

7 Clusters de alta disponibilidade

O termo cluster aplicado a uma vasta gama de configuraes de computadores com
mltiplos processadores. Em comum, as vrias configuraes de clusters compreendem
um nmero varivel de nodos de computao convencionais (de 2 nodos a poucos
milhares), alguns dispositivos de armazenamento compartilhados e interconexes de
alta velocidade. Clusters lembram os supercomputadores paralelos dos anos 80 e 90 e
geralmente so associados a alto desempenho. Entretanto, na prtica, cluster so mais
similares a sistemas distribudos [BIR96] e so usados tanto para alcanar alto
desempenho quanto alta disponibilidade, ou ambos.
Clusters permitem processamento paralelo: dois ou mais nodos trabalham cooperativamente, compartilhando recursos de processamento e de entrada e sada. Uma
aplicao suportada por um cluster executa seus processos concorrentemente em vrios
nodos, aumentando assim seu desempenho. Nodos em um cluster podem acessar e
compartilhar os mesmos dispositivos de armazenamento, substituindo uns aos outros em
caso de falha de hardware ou software. A capacidade de nodos operacionais
substiturem nodos defeituosos torna a arquitetura cluster interessante para aplicaes
que exigem alta disponibilidade. Arquiteturas cluster fornecem ainda: (a) um alto grau
de escalabilidade, (b) a habilidade de gerenciar mltiplos servidores como se fossem um
s e (c) a habilidade de equilibrar a carga de trabalho mais efetivamente fazendo um
melhor uso do hardware disponvel.
Arquiteturas cluster so ideais para o fornecimento de servios altamente disponveis.
Em clusters de alta disponibilidade (HA-clusters), alguns nodos permanecem prontos
para a qualquer momento assumir a carga de trabalho de nodos que apresentarem
defeito, sem contribuir para o aumento de desempenho. Esses clusters tambm facilitam
as tarefas de manuteno. Um nodo pode ser retirado, desligado ou substitudo sem
interrupo de servio.
HA-clusters geralmente no compartilham a carga de processamento como os clusters
de alto desempenho, nem distribuem trfego como clusters que balanceiam carga.
Em clusters rodando servios altamente disponveis, alm da base de dados replicada, o
sistema operacional automaticamente migra os servios de um nodo defeituoso para um
nodo operacional e, automaticamente, reinicia as aplicaes.

7.1 Compartilhamento de recursos de armazenamento

Clusters so semelhantes a sistemas distribudos e como tal no possuem memria
compartilhada. Compartilhamento de dados pode ser realizado simplesmente atravs de
troca de mensagens ou por armazenamento de arquivos em um disco comum. Em
funo do compartilhamento de disco, clusters podem ser descritos como:
sistemas de disco compartilhado: necessitam de um gerenciador bloqueio para

organizar as requisies de acesso simultneo a arquivos. Um arquivo sendo

escrito por um nodo do cluster no pode ser aberto para escrita em outro nodo.

Taisy Silva Weber

41

 sistemas que no compartilham armazenamento: cada nodo no cluster efeti-

vamente independente, toda a interao por troca de mensagens.

Existem sistemas, algumas vezes classificados como cluster, que apresentam memria
compartilhada atravs de hardware especial. Nesse caso, os nodos usam um barramento
rpido de memria compartilhada, o que d a cada nodo acesso ao espao de memria
de todo o sistema. Entretanto, esses nodos precisam estar muito prximos fisicamente
uns das outros, enquanto que nodos em sistemas que no compartilham memria podem
estar geograficamente distantes uns dos outros.
Sistemas sem armazenamento compartilhado so os mais populares. Nesse caso, os
nodos so servidores efetivamente independentes, unidos por uma rede de alta
velocidade e coordenados pelo software de cluster.
Uma barreira para a efetiva independncia entre os nodos a necessidade de conectar os
servidores a altas velocidades. Uma Fast Ethernet pode ser suficiente para recuperao
de falhas. Mas se suporte a alto desempenho e longas distncias desejado, ento uma
largura de banda muito maior e no contenciosa deve ser usada. Entre as solues, um
exemplo o ServerNet da Tandem, um tipo de backbone de alta velocidade
desenvolvida pela Microsoft, pela Intel e pela Compaq (agora proprietria da Tandem)

7.2 Exemplos de cluster de alta disponibilidade

O primeiro cluster de sucesso foi o sistema VAXcluster da Digital. Era formado por
nodos VAX fisicamente conectados a um dispositivo central em uma topologia estrela.
No sistema operacional, cada nodo tinha sua prpria identidade, drives e perifricos
[SUW99].
A generalizao da arquitetura cluster para outros fornecedores de sistemas UNIX foi
dificultada porque no UNIX original no existia um maneira automtica para criar
informao distribuda de usurios, nem para compartilhar o sistema de arquivos atravs
da rede. Hoje em dia, a arquitetura cluster se tornou comum, principalmente porque
muitas companhias acharam melhor investir em clusters a sofrer perdas devido a falhas
no sistema.
Um bom exemplo de HA-clusters comerciais so os clusters formados por nodos SUN
Enterprise (http://www.sun.com), que possuem caminhos redundantes entre todos os
nodos, entre todos os subsistemas de disco e para todas as redes externas. Nenhum
ponto nico de falha de hardware, software ou rede afeta a continuidade de servio
no cluster. Um software de gerenciamento de falha detecta falhas e gerencia a
recuperao automaticamente. Em clusters SUN que rodam Oracle Parallel Server, uma
rplica da base de dados logicamente presente em cada nodo, e a base de dados
permanece disponvel enquanto pelo menos um nodo permanecer ativo.
Outro exemplo o pacote para servidores Linux, denominado Piranha
(http://www.sources.redhat.com/piranha), que permite a servidores proverem servios
de alta disponibilidade sem hardware especial. O cluster totalmente baseado em
software, com os servidores interagindo atravs de uma rede de alta velocidade. Piranha
tanto pode ser configurado para alta disponibilidade como para balanceamento de carga.

Taisy Silva Weber

42

7.2.1

Cluster SUN Enterprise

O Sun Enterprise Cluster baseado em um conjunto comum de servios do sistema e

interconexes entre servidores Sun Enterprise. um sistema de cluster assimtrico, os
nodos no cluster no precisam ser idnticos. mais adequado, entretanto, manter o
hardware dos diferentes nodod com poder de processamento equilibrado. Assim, o
sistema no sofrer uma grande queda no desempenho caso o nodo principal falhe.
O nmero mximo de nodos em um Sun Enterprise Cluster 256. Entretanto o limite
prtico realmente depende dos tipos de servidores e suas conexes. Cada cluster
formado de acordo com uma topologia de servidores e conectividade de discos.
Dependendo da topologia, do nmero de conexes entre os servidores, conexes entre
os servidores e os discos e conexes pblicas, o custo pode variar significativamente.
Em geral, quanto mais conexes, maior a confiabilidade, a disponibilidade e tambm o
custo. Entretanto, enquanto a capacidade de processamento do cluster aumenta com
cada nodo adicional, eventualmente o desempenho pode saturar ou at diminuir.
Confiabilidade e compartilhamento de carga de trabalho so atingidos atravs de uma
identidade de rede nica a todo o cluster. Servios de rede para cada nodo existem como
antes, mas o cluster visto como uma nica entidade, com um nico endereo de IP e
um nico host name. Esse endereamento permite que os usurios se conectem atravs
do nome do cluster e sejam redirecionados para o nodo do cluster com a menor carga de
trabalho. Alm disso, caso o nodo falhe, um outro membro do cluster toma o seu lugar
sem perda de conexo.
Essa viso de sistema nico se estende para os dispositivos e processos. Por exemplo, o
identificador de processo do UNIX (pid) nico entre todos os membros do cluster,
assim como identificadores de dispositivo terminal (o tty do UNIX) e ns de estrutura
de diretrio (o vnode do UNIX). Assim, aplicaes no necessitam modificaes para
serem executadas em um cluster. Uma imagem de aplicao de servidor de Web nico
pode ter processos de sesso HTTP individuais rodando em todos os nodos, distribuindo
a carga sempre que possvel sem a necessidade de desenvolver uma verso especial do
software de servidor de Web compatvel com o cluster. O administrador tambm
capaz de migrar manualmente um processo em execuo de um nodo para outro, por
qualquer propsito de manuteno, sem qualquer interrupo de servio.
7.2.2

Microsoft Cluster Server

Clusters da Microsoft foram previstos para ser implementados em duas fases. A

primeira delas o Microsoft Cluster Server (MSCS), que faz parte da Enterprise Edition
do Windows NT Server 4.0. O MCS somente proporciona meios bsicos de recuperao
de falhas no modelo primrio-backup para dois nodos. A fase dois est relacionada ao
Windows
2000
Advanced
Server.
Na
pgina
http://www.microsoft.com/windows2000/technologies/clustering/default.asp
do
fabricante podem ser encontrados documentos detalhados sobre cluster com Windows
2000, assim como anlises de desempenho, documentao e estudos de casos.
Em sua configurao original, o NT j possui sistemas de arquivo (NTFS e DFS) que
podem ser compartilhados atravs da rede. As maiores limitaes da arquitetura cluster
NT esto relacionadas ao seu sistema operacional e ao seu modelo de aplicao. Na

Taisy Silva Weber

43

maior parte, as aplicaes do Windows so projetadas para um nico usurio. Alm

disso, a interface grfica para essas aplicaes as liga fortemente ao sistema
operacional. O fato do processamento grfico sobrecarregar o servidor, escalar o
nmero de usurios exige que se escale proporcionalmente a carga de processamento
grfico no servidor, quando este deveria estar fazendo o processamento de dados e
deixando o processamento grfico para as estaes cliente.
O MSCS exige, para armazenamento, SCSI compartilhada que pode ser trocada entre os
dois nodos no cluster. Exige tambm um link dedicado entre os dois nodos. No
existem restries quanto tecnologia que pode ser usada: uma conexo Fast Ethernet
ou uma tecnologia de interconexo adaptada, como o ServerNet.
Qualquer que seja a tecnologia escolhida, a conexo entre os dois servidores transmite
um sinal para que o software de cluster possa monitorar o estado dos sistemas primrio
e backup. A implementao da Microsoft um pouco diferente da maioria dos clusters
primrio/backup pelo fato de que sinais separados podem ser configurados para
aplicaes particulares. Isso permite que o software recupere falhas de determinados
programas, e no de todo o servidor. Ela tambm usa algo conhecido como recurso de
quorum (que, na primeira verso do software, um disco compartilhado) para ajudar a
solucionar problemas que podem ocorrer na interconexo. Apenas um sistema de cada
vez pode ter a posse desse recurso e assim, em caso de falha na comunicao em uma
das conexes, os dois nodos tomam posse do disco de quorum para determinar
exatamente qual nodo deve continuar rodando.
O MSCS pode tambm ser configurado tanto como uma soluo ativa/passiva quanto
como uma soluo ativa/ativa. Assim, o sistema de backup no necessita ser dedicado
exclusivamente tarefa sendo executada no primrio, e nem necessita ser idntico ao
primrio. O software envolvido executado como um servio sobre o sistema
operacional Windows NT, permitindo que um servidor virtual e recursos virtuais sejam
configurados. Entretanto, existe uma grande diferena na maneira como isso lidado no
MSCS: uma ferramenta grfica de administrao do cluster pode ser executada
remotamente de qualquer estao de trabalho NT na rede [PCM99]. O MSCS tambm
permite mover manualmente recursos de um servidor no cluster para outro (para
permitir manuteno programada, por exemplo), e configurar o software de recuperao
de falhas para atuar automaticamente na reintegrao de servidores.
O MSCS suporta apenas TCP/IP, sendo que o software automaticamente move o
endereo de IP designado para o servidor de cluster virtual cujo servidor no par de
cluster estiver ativo no momento em que um evento de recuperao de falha for
detectado [PCM99].
7.2.3

Tandem ServerNet

A Tandem uma antiga fornecedora no mercado de cluster, com o cluster Himalaya

baseado, em RISC, e o software de clusterizao NonStop. A Tandem tambm
comercializa o software NonStop na forma de middleware, para uso conjunto com o
Unix e o NT sobre plataforma Intel, com particular nfase no suporte para
processamento de transaes e aplicaes de armazenamento de dados.

Taisy Silva Weber

44

A Tandem responsvel por uma das tecnologias mais avanadas em

interconectividade, o ServerNet, que se encontra no centro de vrias solues de
clusterizao (http://www.tandem.com) O ServerNet no apenas permite que os nodos
em um cluster se comuniquem entre si, mas tambm que cada nodo independente
interaja com outros sistemas atravs da rede. O ServerNet pode ser usado para suportar
tanto clusters com disco compartilhado (shared disk) quanto clusters sem
compartilhamento (shared nothing), e essa flexibilidade, somada imensa largura de
banda fornecida, permite lidar com alto desempenho, assim como alta disponibilidade
convencionais [PCM99].
Comunicao em alta velocidade alcanada atravs do uso de uma rede de roteadores
interconectados. A interface entre os roteadores e os servidores se d atravs de
adaptadores PCI plug-in, cada um capaz de suportar at 300Mbps. Isso significa
50Mbps em cada um dos seis links possveis (efetivamente 100Mbps, pois a
transferncias so todas bidirecionais). A tecnologia ServerNet tambm capaz de
acessar informaes de nodos distantes, como tambm enviar requisies de
informaes, e de usar uma tcnica chamada wormhole routing para facilitar o aumento
da taxa de transferncia de dados. E, diferente dos sistemas multiprocessadores com
memria compartilhada, no existe a necessidade de os nodos no cluster estarem to
prximos uns dos outros, ou unidos usando qualquer tipo de barramento do sistema.
Particularmente, os nodos em um sistema ServerNet podem estar a uma distncia de at
30m, unidos por cabos de par tranado simples, atravs dos quais o ServerNet pode
proporcionar uma largura de banda completa de 50Gbps ou mais O resultado uma
comunicao entre os nodos muito rpida.
O ServerNet por si prprio apenas proporciona a infra-estrutura de suporte para clustes.
So necessrios pacotes especiais ou extenses no sistema operacional para permitir
tirar o mximo de vantagem das caractersticas oferecidas.
Essa tecnologia suportada por outras companhias, como a Oracle com o Oracle
Parallel Server (OPS), o Orion da Novell e o Microsoft Cluster Server. O ServerNet
tambm suporta a especificao Virtual Interface (VI), um padro para a tecnologia de
conexo em clusters desenvolvido pela Tandem, Microsoft e Intel, entre outras,
7.2.4

Clusters Linux

Servidores independentes executando o sistema operacional Linux podem ser agrupados

em um cluster sem necessidade de hardware adicional, exceto uma conexo de alta
velocidade. Um cluster Linux pode ser baseado puramente em software.
Nem todos os pacotes para cluster suportados por Linux so de software livre e
independentes de hardware especial. Por exemplo o Linux Network Evolocity (http:
//www.linuxnetworx.com) um produto comercial que compreende hardware e
software. O RHHAS (Red Hat High Availability Server) tambm um produto
comercial cujo ncleo formado pelo software livre Piranha.
A IBM tambm vem desenvolvendo produtos para cluster Linux como sistema de
arquivos - IBM General Parallel File System (GPFS) for Linux (http://www1.ibm.com/servers/eserver/clusters/software/gpfs.html), software de gerncia de cluster
- IBM Cluster System Management (CSM) for Linux (http://www-

Taisy Silva Weber

45

1.ibm.com/servers/eserver/clusters/software/)
e
inclusive
hardware
especial
(http://www-1.ibm.com/servers/eserver/clusters/hardware/1300.html) - o IBM eServer
Cluster 1300.
Uma ferramenta desenvolvida no projeto Linux-HA, denominada Heartbeat (http:
//www.heng.com/alanr/ha/) permite configurar um nodo de backup para qualquer outro
nodo em um cluster. O funcionamento simples e usa uma antiga tcnica de tolerncia
a falhas: o nodo backup monitora continuamente o funcionamento do nodo primrio
enviando para esse sinais peridicos (pings por exemplo); caso o nodo primrio falhe, o
backup assume o seu lugar. A troca de um nodo por outro se d pela falsificao de
pacotes ARP (Address Resolution Protocol), o nodo backup assume o lugar do principal
enganando os demais nodos na rede.
Na Tabela 11 so mostradas algumas outras alternativas de pacotes de software
dirigidos a servidores Linux para construo de clusters de alta disponibilidade.
Produto

Descrio

SteelEye Lifekepper
http://www.steeleue.com

Disponvel para servidores Linux, Unix e

NT

Piranha
http://www.sources.redhat.com/piranha

Fornecido junto a distribuio Red Hat

Linux 6.2. Piranha livre. Prov servios
de "failover" (um servidor com defeito
substitudo por outro operacional).

TurboCluster EnFusion
http://www.turbolinux.com

Para distribuio TurboLinux. Pode

integrar Solaris e NT no cluster.

Linux-HA
http://www.linux-ha.org

Projeto de desenvolvimento de software de

alta disponibilidade. Permite configurar
clusters com primrios e backups.

Tabela 11 - Exemplos de software para cluster Linux

7.3 Disponibilidade em HA-clusters

A disponibilidade alcanada em clusters bastante significativa [SUW99]. Por
exemplo, 99% de disponibilidade significa que o cluster pode rodar 24 horas por dia, 7
dias por semana, 52 semanas por ano com uma possvel indisponibilidade de aproximadamente 5 dias, para manuteno planejada ou no. Para muitas empresas, isso satisfatrio. Mas alguns sistemas de misso crtica (como transaes bancrias, bolsas de
valores, algumas aplicaes mdicas, guia e monitoramento militar ou controle de
trfego areo) exigem um grau mais elevado de disponibilidade. Nesses casos, 99,999%
de disponibilidade significa uma indisponibilidade de cerca de 5 minutos por ano.
A dependabilidade mais alta em um cluster do que a alcanada por meio de vrios
servidores independentes. Uma vez que o cluster visto como uma nica mquina,
existe apenas um ambiente para monitorar e gerenciar [SUW99]. Os vrios usurios e
sistemas de armazenamento esto localizados no mesmo ambiente, tornando mais fcil a
localizao de problemas e mais rpido o reparo.

Taisy Silva Weber

46

Um cluster oferece um potencial para desempenho e disponibilidade aumentados, mas

atingir uma mais alta disponibilidade pode ser difcil. Um cluster estar fisicamente
localizado em um lugar nico, e se ocorrerem acidentes como incndio ou inundao,
um ataque terrorista ou a fonte de energia do prdio for cortada, a disponibilidade do
cluster se torna nula. Um sistema distribudo, que replica o estado crtico entre locais
distantes, poderia sobreviver a tais acidentes com pouca ou nenhuma interrupo no
servio. Enquanto seguro afirmar que um cluster oferece opes animadoras para o
desenvolvedor de uma aplicao de misso crtica, tambm claro que muitos outros
aspectos devem ser considerados para se alcanar uma confiabilidade elevada ou uma
maior disponibilidade. Nesses caso, outras opes devem ser analisadas, como
replicao interna ao nodo para deteco de erros ou mascaramento de falhas.

Taisy Silva Weber

47

8 Tolerncia a Falhas em Sistemas Distribudos

Sistemas distribudos so construdos por vrios nodos processadores independentes.
Esses sistemas se diferenciam de computadores paralelos pelo acoplamento fraco entre
os nodos, ou seja, os elementos de um sistema distribudo no tem acesso a uma
memria comum. Toda a interao deve ser feita por troca de mensagens atravs de
canais de comunicao. Nodos de um sistema distribudo tambm no tem acesso a um
relgio global, portanto no possuem uma base de tempo comum para ordenao de
eventos. Alm disso, sistemas distribudos so geralmente construdos com elementos
no homogneos e assncronos.
Sistemas distribudos no so sinnimo de redes de computadores. Uma rede de
computadores pode fornecer a infraestrutura computacional para um sistema distribudo,
mas nem toda aplicao de rede necessariamente distribuda. Por exemplo, uma rede
onde cada servidor roda uma aplicao e os demais nodos so clientes dessa aplicao
no apresenta os problemas de consistncia de dados e sincronizao tpicos de
problemas distribudos. Por outro lado, um cluster de alto desempenho com centenas e
at milhares de nodos pode ser considerado um sistema distribudo, sem
necessariamente ser suportado por um rede.
Sistemas distribudos apresentam um redundncia natural, extremamente proveitosa
para o emprego de tcnicas de tolerncia a falhas. Defeito em um nodo processador ou
na rede de comunicao no precisa provocar necessariamente a queda de todo o
sistema, e o sistema pode ser reconfigurado usando apenas os nodos disponveis.
A rea de tolerncia a falhas em sistemas distribudos vasta e excitante. Garantir
dependabilidade envolve solucionar problemas de consenso, ordenao e atomicidade
na troca de mensagens entre grupos de processos, sincronizar relgios quando
necessrio, implementar rplicas consistentes de objetos, garantir resilincia de dados e
processos num ambiente sujeito a quedas de estaes tanto clientes como servidoras,
particionamento de redes, perda e atrasos de mensagens e, eventualmente,
comportamento arbitrrio dos componentes do sistema. Leitores interessados no assunto
podem encontrar maiores detalhes nos livros do Jalote (Jal94), Birman (Bir96) e
Mullende (Mul93).

8.1 Motivao para tolerncia a falhas em sistemas distribudos

Um sistema distribudo deve prover operao continuada, com apenas pequena queda de
desempenho, mesmo na presena de qualquer tipo de falha. Apesar de se conhecer um
bom conjunto de tcnicas de tolerncia a falhas, sua aplicao a sistemas distribudos,
principalmente os de tempo-real, ainda muito recente e seus resultados so muitas
vezes insatisfatrios.
Sistemas distribudos tempo-real diferem dos sistemas convencionais por apresentarem
restries de tempo e tratarem, em muitos casos, com situaes crticas. Isto implica que
qualquer tipo de falha, inclusive falha temporal, pode causar conseqncias irreparveis.
Tolerncia a falhas nesses sistemas uma exigncia bvia e consolidada. suportada
regularmente pelo hardware do sistema. Com a complexidade aumentada por um

Taisy Silva Weber

48

nmero maior de componentes de software e sofisticadas interaes, novas solues

para sistemas distribudos passveis de implementao em vrios nveis de software e
hardware precisam ser desenvolvidas e validadas quanto a correo e temporizao.

8.2 Classificao das tcnicas de tolerncia a falhas em camadas

Jalote [Jal94] apresenta uma interessante classificao em camadas das tcnicas e
servios para alcanar dependabilidade em sistemas distribudos. Essa classificao
pode ser representada conforme a Figura 15. Alguns das camadas, blocos bsicos,
recuperao e resilincia de dados sero mencionadas brevemente nesse texto.

servios
software tolerante a falhas
resilincia de processos
resilincia de dados
aes atmicas
recuperao para um estado consistente
blocos
bsicos

difuso confivel e atmica

processador fail-stop, armazenamento estvel,
comunicao confivel
sistema distribudo
Figura 15: Classificao em camadas segundo Jalote

8.3 Modelos de sistemas distribudos

Sistemas distribudos no possuem memria compartilhada nem relgio global. Toda
interao entre processos deve ser realizada por troca de mensagens.
Uma melhor anlise das caractersticas de um sistema distribudo pode ser conduzida
considerando um modelo fsico e um modelo lgico. No modelo fsico os componentes
so a rede de comunicao e os nodos (processador, relgio local, memria local voltil,
armazenamento no voltil, interface de rede, software). No modelo lgico a aplicao
vista como distribuda, a rede considerada completamente conectada e os canais
entregam mensagens na ordem que foram enviadas, mas no existe ordenao total de
mensagens, apenas ordenao parcial.

Taisy Silva Weber

49

Os sistemas distribudos so classificados como sncronos ou assncronos, dependendo

se existe um limite de tempo finito e conhecido para troca de mensagens. usual
tambm o conceito de time-out associado aos sistemas sncronos.
A ordenao de eventos relaciona a dificuldade de determinar relaes temporais devido
inexistncia de um relgio global, ou seja, determinar a ordenao temporal de
eventos que ocorrem em nodos diferentes, medidos por relgios diferentes. Relgios
lgicos (introduzidos por Lamport em 1978) so um meio de assinalar um nmero a um
evento. No possuem nenhuma relao com o tempo fsico. Podem ser implementados
atravs de timestamps. O relgio lgico pode ser usado para ordenao total de eventos
e suficiente para a maior parte das aplicaes que no exigem respostas crticas quanto
ao tempo.

8.4 Falhas em sistemas distribudos

Algumas caractersticas bsicas devem ser consideradas para alcanar dependabilidade
em sistemas distribudos. Dependabilidade pode ser necessria, em maior ou menor
grau, dependendo da aplicao. Mas todos os sistemas distribudos devem suprir um
mnimo de confiabilidade para permitir operao continuada do sistema mesmo com
queda de um ou mais de seus nodos e canais.
Modelos clssicos de falhas para sistemas distribudos so os de Cristian - falhas de
crash, omisso, temporizao, resposta e arbitrria - (Figura 16) e Schneider, que
estende o modelo de Cristian. - fail-stop, crash, omisso de envio, omisso de recepo,
temporizao, resposta e arbitrria. Os dois modelos refletem falhas que afetam as
trocas de mensagem entre os nodos.

parada ou perdado
estado interno

sem resposta para

algumas entradas

crash
omisso
resposta
temporizao

respostas incorretas
para algumas entrada

arbitrria
resposta adiantada
ou retardada

comportamentototalmente
arbitrrio e imprevisvel

Figura 16: Modelo de falhas em sistemas distribudos

Taisy Silva Weber

50

8.5 Processadores Fail-stop e armazenamento estvel

O sistema deve preservar seu estado global mesmo na presena de falhas. Para tanto
necessrio que seus nodos possuam armazenamento estvel. O armazenamento estvel
preserva as informaes armazenadas mesmo na ocorrncia de falhas.
Deve ser lembrado, entretanto, que falhas podem ocorrer inclusive no armazenamento
secundrio, seja disco magntico ou tico. Assim o armazenamento secundrio no
pode ser considerado armazenamento estvel. Infelizmente armazenamento estvel ideal
apenas uma abstrao terica, mas algumas solues prticas como RAID ou
espelhamento de memria permitem chegar prxima a essa abstrao.
O melhor comportamento sob falha para os nodos de um sistema distribudo
simplesmente parar toda e qualquer operao na presena de uma falha interna
irrecupervel, assim os demais nodos podem detectar seu estado pela ausncia de
mensagens. Armazenamento estvel e componentes fail-stop so dois conceitos
importantes aqui.

processadores
P1

Pk

k+1 mensagens
sincronizadas

detecta
falta de mensagem
ou discordncia de ordem
ou contedo
armazenamento
estvel
Ps
falha em qualquer processador
bloqueia operaes sobre o
armazenamento estvel

Pk+1
executam mesma sequncia
de requisies para Ps

Figura 17: Processador k+1 fail-stop

Assim como armazenamento estvel, processadores fail-stop so apenas uma abstrao.
Processadores fail-stop, apesar de serem assumidos por grande parte das solues
prticas de tolerncia a falhas, so existem. Uma aproximao so processadores k+1
fail-stop como mostrado na Figura 17. Esses processadores toleram k falhas.

8.6 Consenso
Em vrias situaes o sistema distribudo deve alcanar um consenso, ou seja, todos os
componentes perfeitos devem contar com os mesmos dados sobre os quais devem
aplicar um mesmo algoritmo de deciso. necessrio resolver o problema de consenso

Taisy Silva Weber

51

entre todos os nodos mesmo na presena de falhas arbitrrias. A compreenso do

problema essencial para entender os protocolos que envolvem troca de mensagens.
O procedimento clssico para alcanar consenso sob falhas arbitrrias em sistemas
sncronos conhecido como o algoritmo dos generais bizantinos e foi apresentado por
Lamport em 1982. O algoritmo garante consenso por troca de mensagens para qualquer
tipo de falha quando o nmero total de nodos for maior ou igual a 3 vezes mais 1 o
nmero de nodos faltosos (chamados de traidores por Lamport).
Lamport mostrou tambm que consenso impossvel em sistemas assncronos com
falhas arbitrrias. Posteriormente Fisher provou que consenso impossvel em sistemas
assncronos considerando qualquer modelo de falhas.
Infelizmente, mesmo em sistemas sncronos, o nmero de mensagens trocadas entre os
nodos insuportvel em um sistema distribudo real, pois provoca uma exagerada queda
de desempenho. Para evitar essa queda, o algoritmo de consenso deve adequar-se a um
modelo mais restritivo de falhas e a outras caractersticas especficas da rede. Uma srie
de algoritmos tm sido publicados com esse objetivo desde a apresentao do algoritmo
de Lamport. Para resolver o problema da impossibilidade de consenso em sistemas
assncronos foram propostos protocolos probabilsticos, que permitem alcanar
consenso com certa probabilidade diferente de 1.

8.7 Protocolos de difuso confivel

Uma tcnica de tolerncia a falhas necessria em sistemas distribudos a difuso
(broadcast) confivel. Nesta tcnica, um processador dissemina um valor para os
demais processadores no sistema. Mesmo na presena de falhas, essa difuso deve ser
confivel, ou seja a mensagem enviada deve ser recebida por todos os nodos
operacionais. Alm disso, pode ser necessrio preencher algumas outras exigncias,
como por exemplo atomicidade e ordenao (parcial, total, causal) de mensagens. Como
na maior parte dos sistemas a comunicao ponto a ponto (um para um), a difuso (um
para todos) envolve uma srie de transmisses de mensagens e torna-se assim
extremamente suscetvel a falha de nodos ou de links de comunicao. Vrios
protocolos de difuso confivel foram desenvolvidos para suportar determinadas classes
de falhas e atendendo uma ou mais exigncias especficas (por exemplo os protocolos
clssicos de Chang, Cristian e Birman [Jal94], [Bir96]).
Diversos procedimentos de tolerncia a falhas baseiam-se em difuso confivel. Sempre
que votao e consenso so necessrios, por exemplo, difuso confivel pode ser
aplicada. Exemplos so sincronizao de relgios, replicao de dados, diagnstico de
sistemas.
Em um sistema distribudo so usados tanto protocolos broadcast, onde a difuso ocorre
para todos os nodos do sistema, como multicast, onde a difuso se restringe a um grupo
de nodos do sistema. Os protocolos devem tratar os problemas envolvidos na difuso de
mensagens em ambientes sujeitos a falhas e a particionamento de redes, inclusive os
problemas que afetem o nodo transmissor durante a execuo do protocolo. Protocolos
para multicast devem tratar, alm disso, o problema de membership, ou seja, a
determinao de quais nodos a cada momento pertencem ao grupo de difuso.

Taisy Silva Weber

52

8.8 Recuperao em sistemas distribudos

Para que o sistema no sofra pane devido a falhas em seus componentes, erros devem
ser detectados o mais rapidamente possvel, o ndo faltoso deve ser identificado atravs
de diagnstico apropriado e finalmente isolado atravs de reconfigurao do sistema.
Essa reconfigurao se faz realocando processos e escolhendo caminhos alternativos de
comunicao entre os processos. Assim, para aumentar a dependabilidade de sistemas
distribudos, deteco de erros, diagnstico e reconfigurao so tcnicas essenciais,
que devem ser incorporadas de forma transparente aplicao e ao seu ambiente de
suporte.
Dependendo do tipo de sistema, da especificao de sua resposta no tempo e dos custos
de implementao, falhas podem ser mascaradas ou erros podem ser recuperados.
Mascaramento mais efetivo em sistemas de tempo real, podendo tambm ser usado em
sistemas convencionais, mas o custo em hardware maior. Nesse caso falhas no se
propagam e o sistema continua seu processamento sem queda de desempenho. As
tcnicas de recuperao por retorno no usam tanta redundncia como as tcnicas de
mascaramento, mas pressupem um estado global anterior seguro armazenado de
alguma forma no sistema e a possibilidade de rollback para esse estado, o que
inviabiliza a sua aplicao a uma vasta gama de sistemas de tempo real usados em
controle de processos contnuos. As alternativas recuperao por retorno so, em
geral, de difcil projeto e implementao e extremamente vinculadas a casos bem
modelados.
A recuperao por retorno, que simples em um sistema com um nico processo, pode
se tornar bastante complexa em um sistema distribudo [Jans97]. A recuperao nesses
sistemas envolve o retorno no apenas dos processos no nodo falho, mas de todos os
processos envolvidos direta ou indiretamente na comunicao com os primeiros, e pode
provocar efeito domin.
Efeito domin significa o retorno sucessivo, e em cascata, de todos os processos do
sistema ao incio da computao, ou prximo ao incio, desfazendo grande quantidade
de processamento.
Q
mensagem perdida
P

PR

falha
rollback

Figura 18: Mensagem perdida

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, eventualmente, que outros processos, que

Taisy Silva Weber

53

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.
Vrios algoritmos tem sido propostos para estabelecimentos de pontos de recuperao
que correspondam a um estado global seguro. Vrios algoritmos tambm sugerem
mecanismos para evitar o efeito domin, para restringir o nmero de pontos de
recuperao que necessitam ser armazenados ou impor restries a comunicao entre
os processos visando evitar o aparecimento de mensagens perdidas (Figura 18) ou rfs
(Figura 19). Jansch-Prto e Weber apresentam um resumo dos algoritmos clssicos
[Jans97].
Q
mensagem rf
P

PR

falha

Figura 19: Mensagem orf

Aps a localizao da falha por procedimentos de diagnstico, o sistema distribudo
pode ser reconfigurado. A reconfigurao envolve a determinao de uma nova
configurao para a rede, o isolamento dos nodos faltosos, redistribuio dos recursos
restantes para as aplicaes, realocao dos processos aos nodos e reinicializao ou
recuperao do sistema. Reconfigurao tambm necessria quando um novo nodo
integrado rede.
Para a determinao de uma nova configurao para a rede necessrio consenso, todos
os novos nodos devem reconhecer a mesma configurao (ou seja quais so os nodos
perfeitos que restaram e qual a topologia de sua interconexo). Aps a migrao dos
processos e sua recuperao, o processamento pode ser reiniciado. Todas essas
operaes devem ser realizadas no menor intervalo de tempo possvel e considerando,
que mesmo nesse pequeno intervalo, novos nodos podem falhar na rede. Deve-se
considerar tambm, no caso de isolamento de nodos, a queda de desempenho gradativa
a qual o sistema est sujeito a cada nova reconfigurao. Essa queda de desempenho
pode inviabilizar algumas aplicaes. A reconfigurao est tambm relacionada ao
gerenciamento e manipulao de grupos de processos no momento da falha.

8.9 Gerenciamento e manipulao de grupos

O tratamento de comunicao de grupo envolve aspectos referentes a forma com que os
processos de um grupo so manipulados no sistema distribudo. Isto conhecido como
group membership, ou associao de grupos. Este tpico est relacionado ao

Taisy Silva Weber

54

gerenciamento e a coordenao dos processos de um determinado grupo do sistema,

tanto no momento da falha como no estgio de reconfigurao do grupo.
Gerenciamento e manipulao de grupos relacionam-se aos aspectos de formao e
coordenao de grupos em sistemas sujeitos a ocorrncia de falhas.
Diversos algoritmos tm sido propostos para resolver o problema de associao de
grupos em sistemas distribudos, sendo uma rea promissora para pesquisas,
principalmente se associada a aspectos de tempo real. Ao contrrio dos tpicos
anteriores que so cobertos por Jalote [JAL94], associao de grupos tratada por
Birman [BIR96].

8.10 Replicao de dados

Os recursos fsicos usados para armazenar arquivos so, por sua prpria natureza,
suscetveis a falhas. Uma ampla gama de falhas pode atingir os meios de
armazenamento, quer sejam falhas no prprio meio, nos dispositivos de controle, nos
computadores que gerenciam estes dispositivos, e, no caso de redes, nos links de
comunicao. O uso de grandes redes institucionais e servidores corporativos, com
dezenas ou centenas de usurios, tende a agravar este problema. Nas redes, aumenta o
nmero de pessoas ou atividades que dependem dos mesmos dispositivos de
armazenamento e servidores de arquivos, criando condies para que aconteam perdas
simultneas, ou em cascata, relacionadas a falhas em algum dos servidores. As
conseqncias de falhas podem ser catastrficas.
Devido a necessidade de confiabilidade no armazenamento de dados, diversas tcnicas
especficas tem sido desenvolvidas para tornar este recurso mais seguro, sem que uma
soluo ao mesmo tempo robusta e administrativamente conveniente tenha sido
assumida como definitiva. O recurso principal continua a ser o "backup" em fita, que
possui o grave inconveniente de ser um mtodo "off-line", e de guardar sempre dados
algo atrasados, alm de implicar em um longo tempo de recuperao.
O aumento de velocidade das redes modernas e sua popularizao permitem a adoo
de tcnicas de replicao de arquivos e a distribuio de rplicas por vrios servidores.
O algoritmo de replicao o centro de todo sistema de replicao de dados distribudo,
e determina de forma decisiva as decises a serem tomadas no tratamento de falhas e na
recuperao.
Um algoritmo de replicao de arquivos deve resolver principalmente o problema da
manuteno da consistncia das cpias sob escritas concorrentes. Em um sistema
multitarefa, diversos processos executam simultaneamente, e podem compartilhar o
acesso aos arquivos, inclusive para escrita. Este recurso permite que arquivos sejam
usados para troca dinmica de informaes entre programas e usurios. Ainda que
leituras concorrentes no gerem nenhum problema, escritas concorrentes podem gerar
inconsistncias. A questo fundamental est em garantir que todas as alteraes geradas
sejam aplicadas em todas as cpias na mesma ordem, alm da necessidade de que
tenham a mesma efetividade. No importa garantir que esta ordem seja a mesma ordem
fsica em que as requisies foram geradas, nem que as imagens que cada cliente tenha
do arquivo sejam as mesmas a qualquer instante, apenas que todas as cpias executem a
mesma seqncia de alteraes.

Taisy Silva Weber

55

Esta ordenao, denominada na literatura como serializao como cpia nica, no

pode ser garantida de forma simples. Os algoritmos desenvolvidos para isto,
denominados algoritmos de controle de rplicas, devem tambm ser capazes de operar
quando da ocorrncia de falhas, quando o nmero de nodos se reduz, ou sob outras
condies, como particionamento da rede, em funo do modelo de falhas adotado.
Os algoritmos de controle de rplicas podem ser divididos em trs grandes grupos:
algoritmos baseados em votao; algoritmos baseados em cpia primria; algoritmos
baseados em cpias ativas. Os dois ltimos podem ser mais facilmente implementados
usando multicast confivel e atmico.

Taisy Silva Weber

56

9 Validao de tcnicas de tolerncia a falhas

Um grande problema na rea de tolerncia a falhas saber se a tcnica implementada
resulta realmente em aumento de confiabilidade. Como na maior parte dos sistemas as
taxas de falhas so baixas e as falhas acontecem de forma aleatria e incontrolvel, o
problema se resume em avaliar se a tcnica empregada est realmente tolerando as
falhas para as quais foi planejada, sem necessidade de esperar meses ou anos para que
as falhas realmente aconteam (por exemplo em avinica, que um sistema crtico, a
taxa de taxas esperada uma em cada um pouco mais de milho de anos). Uma soluo
para esse problema a injeo de falhas.
Injeo de falhas relativamente popular em sistemas isolados. recente, entretanto, o
desenvolvimento de ferramentas de injeo de falhas para sistemas distribudos, e pouca
experincia foi acumulada no tema. Uma breve introduo a essa tcnica
particularmente til ao desenvolvedores de tcnicas de tolerncia a falhas em ambiente
distribudo.
O principal objetivo da injeo de falhas a validao. A injeo de falhas pode ser
vista como um procedimento para o teste da eficcia de tcnicas de tolerncia a falhas.
Atravs da introduo controlada de falhas, o comportamento da tcnica, sob falhas,
pode ser avaliado (ou seja, pode ser determinado se a tcnica permite ao sistema tolerar
ou no as falhas injetadas e qual o custo relacionado a cobertura de falhas alcanada).
A injeo de falhas tem uma importncia vital em sistemas crticos de tempo real,
sujeitos a graves perdas e danos caso tcnicas de tolerncia a falhas no consigam
garantir a confiabilidade especificada. Tambm em sistemas de transaes, onde falhas
podem provocar inconsistncias (como em operaes bancrias) no permitido esperar
que falhas reais durante a operao normal do sistema venham a determinar que as
tcnicas empregadas no foram bem concebidas ou implementadas. Outros exemplos
so em sistemas distribudos e sistemas paralelos. Nesses sistemas, o complexidade dos
subsistemas de conexo e comunicao facilitam a propagao de falhas e dificultam
sua deteco. Sem controle sobre o tipo e origem das falhas torna-se extremamente
difcil validar a implementao de tolerncia a falhas nesses sistemas.
Injeo de falhas pode ser aplicada ao sistema simulado ou a sistemas fsicos operando
em seu ambiente natural. Por exemplo: injeo de falhas a nvel de pinos e atravs de
distrbios externos. As tcnicas de injeo de falhas a nvel de pinos e atravs de
distrbios externos tem a vantagem de injetar falhas diretamente no hardware, mas
podem danificar o componente sob teste e requerem o uso de hardware especial
dedicado. Adicionalmente as ferramentas de injeo so especficas a um determinado
sistema.
Ferramentas de injeo de falhas implementadas por software no requerem hardware
especial para serem aplicadas. Possuem ainda como vantagens baixo custo, baixa
complexidade e baixo esforo de desenvolvimento. So facilmente adaptveis a novas
classes de falhas, e no apresentam nenhum problema com interferncias fsicas.
Contudo, a injeo de falhas implementada por software apresenta alguns problemas. A
capacidade para modelar certos tipos de falhas, tais como aquelas afetando as unidades
de controle de um processador, ainda no foi totalmente desenvolvida. Alm disso, a

Taisy Silva Weber

57

execuo do software responsvel pela injeo de falhas afeta as caractersticas de

temporizao do sistema, o que prejudica a execuo de funes crticas no tempo.
Mesmo considerando essas desvantagens, injeo de falhas implementada por software
tem despertado o maior interesse de pesquisadores e desenvolvedores. A maioria das
ferramentas de injeo de falhas mais recentes enfocam sistemas distribudos,
relacionados com falhas de processador, memria e comunicao. Estas ferramentas
(como por exemplo FIAT, SFI, DOCTOR, FINE, PFI) injetam falhas por software.
O captulo 5 do livro do Pradhan [Prad96] escrito por Iyer e Tang traz um tima
introduo a injeo de falhas. Um artigo de Hsue [Hsu97] um resumo interessante
sobre o tema.
No Brasil pesquisa em injeo de falhas tem sido conduzidas principalmente pelos
grupos de pesquisa das professoras Eliane Martins, na Unicamp, e Taisy Weber, na
UFRGS. Nos anais do SCTF e WTF podem ser encontrados relatos sobre esses
trabalhos.

Taisy Silva Weber

58

10 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 software cada vez mais
complexo, 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.
O texto apresentou ainda uma rpida viso sobre os problemas de falhas em sistemas
distribudos e suas possveis solues. Esse texto no visa substituir um livro texto na
rea. Vrios deles so recomendados ao longo da leitura. Um maior aprofundamento
visando pesquisas acadmicas podem ser obtidas nos anais dos eventos da rea, tanto
internacionais como o DSN, como os nacionais SCTF e WTF.
Os exemplos de sistemas tolerantes a falhas citados no texto no representam uma lista
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 e se mostram um pouco mais dispostos a
enfrentar os custos adicionais das tcnicas de tolerncia a falhas.
Convm ressaltar que mesmo para as reas onde se dispe de sistemas tolerantes a
falhas, esses nem sempre se apresentam prontos para a imediata utilizao. O
desenvolvedor de software, ou o usurio especializado desses sistemas, deve muitas
vezes prover alguns recursos complementares para garantir a confiabilidade ou a
disponibilidade desejada para a 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 so raramente disponveis devido ao
elevado custo associado.
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
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.
Profissionais de computao devem encarar seriamente os problemas ocasionados por
falhas no tratadas nos sistemas informatizados. Tolerncia a falhas compreende muitas

Taisy Silva Weber

59

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.

Taisy Silva Weber

60

11 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

[BUY99] BUYYA, Rajkumar. High Performance Cluster Computing. Volume 1.

Upper Saddle River, Prentice-Hall, 1999.
[ChAv78] CHEN, L.; AVIZIENIS, A. N-version programming: a fault tolerance
approach to reliability of software operation. In: Annual International
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.

[Goer89]

GRKE, W. Fehlertolerante Rechensysteme. Mnchen, Oldenburg Verlag,

1989.

[HSL78]

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.

[Hsu97]

HSUEH, M. et. al. Fault Injection Techniques and Tools. IEEE Computer,
v. 30, n. 4, Apr. 1997.

[IEEE01] IEEE Computer Society. FTCS/DSN 1971-2001 Compendium.

[Jal94]

JALOTE, P. Fault tolerance in distributed systems. Prentice Hall,

Englewood Cliffs, New Jersey, 1994.

[Jans97]

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

[John84]

JOHNSON, D. The Intel 432: a VLSI architecture for fault-tolerant

computer systems. Computer, New York, 17(8):40-48, Aug. 1984.

[Katz78]

KATZMAN, J. A. A fault-tolerant computing system. In: Hawaii

International Conference of System Sciences, 1978, Proceedings. p. 85-102.

[Lapr85]

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.

Taisy Silva Weber

61

[Lapr98]

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.

[Liu84]

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.

[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]

MULLENDE, S. Distributed systems. Addison-Wesley, ACM Press, New

York, 1993.

[PCM99] PC Magazine UK Guide to Clustering. Disponvel por www em

http://www.zdnet.co.uk/pcmag/ (outubro de 1999)
[PRA96]

PRADHAN, Dhiraj. Fault-Tolerant Computer Design. Englewood Cliffs,

Prentice-Hall, 1996.

[Prad96]

PRADHAN, D. K., Fault-Tolerant System Design. Prentice Hall, New

Jersey, 1996.

[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.
[SUW99] Sun World. Disponvel por www em http://www.sunworld.com (agosto de
1999)
[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.
[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.

Taisy Silva Weber

62