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

universo da informao universo fsico falha

processamento posterior pode levar a defeito

erro universo do usurio

defeito
desvio da especificao

Figura 1: Modelo de 3 universos: falha, erro e defeito 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 MTTF: 6 a 12 semanas Indisponibilidade aps defeito: 1 a 4 horas Defeitos: hardware software comunicao/ambiente operaes 50% 25% 15% 10% Tolerantes a falhas MTTF: 21 anos (Tandem) Defeitos: software operaes hardware ambiente Redes cliente-servidor (no tolerantes a falhas) Disponibilidade mdia: 98% Defeitos: projeto operaes fsicos

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) Disponibilidade (availability) Segurana (safety) Segurana (security) capacidade de atender a especificao, dentro de condies definidas, durante certo perodo de funcionamento e condicionado a estar operacional no incio do perodo probabilidade do sistema estar operacional num instante de tempo determinado; alternncia de perodos de funcionamento e reparo probabilidade do sistema ou estar operacional e executar sua funo corretamente ou descontinuar suas funes de forma a no provocar dano a outros sistema ou pessoas que dele dependam proteo contra falhas maliciosas, visando privacidade, autenticidade, integridade e irrepudiabilidade dos dados 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 t

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 Taxa de defeitos - failure rate, hazard function, hazard rate

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

MTTF - mean time to failure MTTR - mean time to repair MTBF - mean time between failure

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 mortalidade infantil

fase de envelhecimento perodo de vida til

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 preveno de falhas tolerncia a falhas validao previso de falhas Funo impede a ocorrncia ou introduo de falhas. Envolve a seleo de metodologias de projeto e de tecnologias adequadas para os seus componentes. fornece o servio esperado mesmo na presena de falhas. Tcnicas comuns: mascaramento de falhas, deteco de falhas, localizao, confinamento, recuperao, reconfigurao, tratamento. remoo de falhas, verificao da presena de falhas. estimativas sobre presena de falhas e estimativas sobre conseqncias de falhas. 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 forward error recovery

Definio

Caractersticas

Implementao

conduo a novo estado eficiente, mas danos especfica a cada ainda no ocorrido desde a devem ser previstos sistema ltima manifestao de erro acuradamente alto custo, mas de aplicao genrica pontos de recuperao (checkpoints), pistas de auditoria, ...

backward conduo a estado anterior error recovery

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 rollback falha

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 replicao de componentes ECC (cdigo de correo de erros) diversidade, programao n-verses blocos de recuperao Aplicado a: qualquer componente de hardware informao transmitida ou armazenada especificao, projetos, programas 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 redundncia passiva ou esttica redundncia ativa ou dinmica redundncia hbrida Tcnicas mascaramento de falhas Vantagens no requer ao do sistema, no indica falha

deteco, localizao substituio de mdulos, usada e recuperao em aplicaes de longa vida 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

VOTADOR

resultado

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

deteco

localizao

reconfigurao

duplicao e comparao

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

deteco e localizao de falha

sistema com defeito

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 alimentados (hot standby) Comentrios Mdulo estepe conectado eletricamente ao sistema. Minimiza a descontinuidade do processamento durante o chaveamento entre os mdulos. Mdulo estepe s comea a operar quando conectado. Aumenta a vida til dos mdulos estepe.

no alimentados (cold standby)

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 resultado

VOTADOR

verso n

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 chave n para 1 teste de aceitao

verso secundria n-1

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

Figura 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
Reconfigurao automtica Fontes de energia e ventilao redundantes ECC para garantir integridade dos dados Monitoramento ambiental Ferramentas de monitoramento avanadas Ferramentas de diagnstico online Troca de componentes com o sistema em operao

Descrio
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. defeito em um desses componentes no interrompe a operao do sistema. ECC usado em todos os caminhos de dados. Adicionalmente, paridade usada nos endereos e linhas de controle do barramento e tambm nas caches. 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. 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. realizam testes e registram os resultados obtidos. Os testes so realizados em componentes (processadores, memria, I/O,), e no sistema como um todo habilidade em substituir componentes sem necessidade de desligar o sistema (hot swap). Mdulos de energia/ventilao, placas de CPU/memria e placas de I/O podem ser instalados e removidos com sistema em operao 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 I C AD O R FI er o r

SA I A D

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 freqentemente 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 efetivamente 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 SteelEye Lifekepper http://www.steeleue.com Piranha http://www.sources.redhat.com/piranha Descrio Disponvel para servidores Linux, Unix e NT Fornecido junto a distribuio Red Hat Linux 6.2. Piranha livre. Prov servios de "failover" (um servidor com defeito substitudo por outro operacional). Para distribuio TurboLinux. Pode integrar Solaris e NT no cluster. Projeto de desenvolvimento de software de alta disponibilidade. Permite configurar clusters com primrios e backups.

TurboCluster EnFusion http://www.turbolinux.com Linux-HA http://www.linux-ha.org

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 arbitrria resposta adiantada ou retardada comportamentototalmente arbitrrio e imprevisvel respostas incorretas para algumas entrada

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 Pk+1

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

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 rollback falha

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. GRKE, W. Fehlertolerante Rechensysteme. Mnchen, Oldenburg Verlag, 1989. HOPKINS, A. L; SMITH, T. B.; LALA, J. H. FTMP - a highly realible fault-tolerant multiprocessor for aircraft. Procedings of the IEEE, New York, 66(10):1221-1239, Oct. 1978. HSUEH, M. et. al. Fault Injection Techniques and Tools. IEEE Computer, v. 30, n. 4, Apr. 1997. JALOTE, P. Fault tolerance in distributed systems. Prentice Hall, Englewood Cliffs, New Jersey, 1994. JANSCH-PORTO, I. E. S; WEBER, T. S. Recuperao em Sistemas Distribudos. In: XVI Jornada de Atualizao em Informtica, XVII Congresso da SBC, Braslia, 2-8 agosto de 1997. anais. pp 263-310 JOHNSON, D. The Intel 432: a VLSI architecture for fault-tolerant computer systems. Computer, New York, 17(8):40-48, Aug. 1984. KATZMAN, J. A. A fault-tolerant computing system. In: Hawaii International Conference of System Sciences, 1978, Proceedings. p. 85-102. 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.

[Goer89] [HSL78]

[Hsu97]

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

[John84] [Katz78] [Lapr85]

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

[Liu84]

[LyVa62] LYONS, R.E.; VANDERKULK, W. The use of triple-modular redundancy to improve computer reliability. IBM Journal of Research and Development. New York, 6(3): 200-209, abr. 1962. [Mul93] 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] [Prad96] PRADHAN, Dhiraj. Fault-Tolerant Computer Design. Englewood Cliffs, Prentice-Hall, 1996. 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