Tolerância ao erro

Da Wikipédia, a enciclopédia livre
  (Redireccionado de Design tolerante a falhas )
Ir para a navegação Saltar para pesquisar

Tolerância a falhas é a propriedade que permite que um sistema continue operando corretamente no caso de falha de uma ou mais falhas em alguns de seus componentes. Se sua qualidade operacional diminui, a diminuição é proporcional à gravidade da falha, em comparação com um sistema projetado ingenuamente, no qual mesmo uma pequena falha pode causar avaria total. A tolerância a falhas é particularmente procurada em sistemas de alta disponibilidade , de missão crítica ou mesmo de vida crítica . A capacidade de manter a funcionalidade quando partes de um sistema falham é chamada de degradação normal . [1]

Um design tolerante a falhas permite que um sistema continue sua operação pretendida, possivelmente em um nível reduzido, em vez de falhar completamente, quando alguma parte do sistema falhar . [2] O termo é mais comumente usado para descrever sistemas de computador projetados para continuar mais ou menos totalmente operacionais com, talvez, uma redução no rendimento ou um aumento no tempo de resposta no caso de alguma falha parcial. Ou seja, o sistema como um todo não é parado por problemas no hardware ou no software. Um exemplo em outro campo é um veículo motorizado projetado para continuar a ser dirigido se um dos pneus for furado, ou uma estrutura que seja capaz de manter sua integridade na presença de danos devido a causas como fadiga , corrosão , fabricação falhas ou impacto.

No âmbito de um sistema individual , a tolerância a falhas pode ser alcançada antecipando condições excepcionais e construindo o sistema para lidar com elas e, em geral, visando a auto-estabilização para que o sistema convirja para um estado livre de erros. No entanto, se as consequências de uma falha do sistema forem catastróficas ou o custo de torná-lo suficientemente confiável for muito alto, uma solução melhor pode ser usar alguma forma de duplicação. De qualquer forma, se a consequência de uma falha do sistema for tão catastrófica, o sistema deve ser capaz de usar a reversão para retornar ao modo de segurança. Isso é semelhante à recuperação de reversão, mas pode ser uma ação humana se humanos estiverem presentes no loop.

História [ editar ]

O primeiro computador tolerante a falhas conhecido foi o SAPO , construído em 1951 na Tchecoslováquia por Antonín Svoboda . [3] : 155  Seu projeto básico era de tambores magnéticos conectados via relés, com método de votação de detecção de erros de memória ( redundância modular tripla ). Várias outras máquinas foram desenvolvidas nessa linha, principalmente para uso militar. Eventualmente, eles se separaram em três categorias distintas: máquinas que durariam muito tempo sem nenhuma manutenção, como as usadas em sondas espaciais e satélites da NASA ; computadores que eram muito confiáveis, mas exigiam monitoramento constante, como aqueles usados ​​para monitorar e controlar usinas nucleares ou experimentos de supercolisor ; e, finalmente, computadores com uma grande quantidade de tempo de execução que estariam sob uso pesado, como muitos dos supercomputadores usados ​​pelas seguradoras para seu monitoramento de probabilidade .

A maior parte do desenvolvimento da chamada computação LLNM (Long Life, No Maintenance) foi feita pela NASA durante a década de 1960, [4] em preparação para o Projeto Apollo e outros aspectos de pesquisa. A primeira máquina da NASA entrou em um observatório espacial , e sua segunda tentativa, o computador JSTAR, foi usada na Voyager . Este computador tinha um backup de matrizes de memória para usar métodos de recuperação de memória e, portanto, foi chamado de computador JPL Self-Testing-And-Repairing. Ele pode detectar seus próprios erros e corrigi-los ou trazer módulos redundantes conforme necessário. O computador ainda está funcionando hoje [ quando? ] .

Computadores hiper-confiáveis ​​foram pioneiros principalmente por fabricantes de aeronaves , [3] : 210  empresas de energia nuclear e a indústria ferroviária nos EUA. Esses computadores precisavam de grandes quantidades de tempo de atividade que falhariam graciosamente o suficiente com uma falha para permitir a operação contínua enquanto contavam com o fato de que a saída do computador seria constantemente monitorada por humanos para detectar falhas. Novamente, a IBM desenvolveu o primeiro computador desse tipo para a NASA para orientação dos foguetes Saturn V , mas mais tarde a BNSF , Unisys e General Electric construíram seus próprios. [3] : 223 

Na década de 1970, muito trabalho aconteceu no campo. [5] [6] [7] Por exemplo, o F14 CADC tinha autoteste e redundância integrados. [8]

Em geral, os primeiros esforços em projetos tolerantes a falhas estavam focados principalmente no diagnóstico interno, onde uma falha indicava que algo estava falhando e um trabalhador poderia substituí-lo. O SAPO, por exemplo, tinha um método pelo qual tambores de memória defeituosos emitiam um ruído antes de falhar. [9] Esforços posteriores mostraram que, para ser totalmente eficaz, o sistema precisava se auto-reparar e diagnosticar - isolando uma falha e, em seguida, implementando um backup redundante enquanto alertava a necessidade de reparo. Isso é conhecido como redundância de modelo N, onde falhas causam falhas automáticas à prova de falhas e um aviso ao operador, e ainda é a forma mais comum de projeto tolerante a falhas de nível um em uso hoje.

A votação foi outro método inicial, conforme discutido acima, com vários backups redundantes operando constantemente e verificando os resultados uns dos outros, com o resultado de que, se, por exemplo, quatro componentes relatassem uma resposta de 5 e um componente relatasse uma resposta de 6, os outros quatro "votaria" que o quinto componente estava com defeito e o tiraria de serviço. Isso é chamado de M de N votos por maioria.

Historicamente, o movimento sempre foi mover-se mais longe do modelo N e mais para M de N devido ao fato de que a complexidade dos sistemas e a dificuldade de garantir o estado transitivo de negativo para falha positivo não interrompeu as operações. .

Tandem e Stratus estavam entre as primeiras empresas especializadas no projeto de sistemas de computador tolerantes a falhas para processamento de transações online .

Exemplos [ editar ]

"M2 Mobile Web", o front-end original da web móvel do Twitter, serviu mais tarde como versão herdada de fallback para clientes sem suporte a JavaScript e/ou navegadores incompatíveis até dezembro de 2020.

A tolerância a falhas de hardware às vezes exige que as peças quebradas sejam retiradas e substituídas por peças novas enquanto o sistema ainda está operacional (em computação conhecida como troca a quente ). Tal sistema implementado com um único backup é conhecido como tolerante a ponto único e representa a grande maioria dos sistemas tolerantes a falhas. Em tais sistemas, o tempo médio entre falhas deve ser longo o suficiente para que os operadores tenham tempo suficiente para consertar os dispositivos quebrados ( tempo médio para reparo ) antes que o backup também falhe. É útil se o tempo entre as falhas for o maior possível, mas isso não é especificamente necessário em um sistema tolerante a falhas.

A tolerância a falhas é notavelmente bem-sucedida em aplicativos de computador. A Tandem Computers construiu todo o seu negócio nessas máquinas, que usaram tolerância de ponto único para criar seus sistemas NonStop com tempos de atividade medidos em anos.

As arquiteturas à prova de falhas podem abranger também o software de computador, por exemplo, por replicação de processo .

Os formatos de dados também podem ser projetados para se degradarem graciosamente. O HTML , por exemplo, foi projetado para ser compatível com versões futuras , permitindo que os navegadores da Web ignorem entidades HTML novas e não suportadas sem tornar o documento inutilizável. Além disso, alguns sites, incluindo plataformas populares como o Twitter (até dezembro de 2020), fornecem um front-end leve opcional que não depende de JavaScript e tem um layout mínimo , para garantir ampla acessibilidade e alcance , como em consoles de jogos com web limitada capacidades de navegação. [10] [11]

Terminologia [ editar ]

Um exemplo de degradação graciosa por design em uma imagem com transparência. Cada uma das duas primeiras imagens é o resultado da visualização da imagem composta em um visualizador que reconhece a transparência. As duas imagens inferiores são o resultado em um visualizador sem suporte para transparência. Como a máscara de transparência (parte inferior central) é descartada, apenas a sobreposição (parte superior central) permanece; a imagem à esquerda foi projetada para se degradar graciosamente, portanto, ainda é significativa sem suas informações de transparência.

Um sistema altamente tolerante a falhas pode continuar no mesmo nível de desempenho mesmo que um ou mais componentes tenham falhado. Por exemplo, um edifício com um gerador elétrico de reserva fornecerá a mesma voltagem às tomadas de parede, mesmo que a energia da rede falhe.

Um sistema que é projetado para evitar falhas , proteger contra falhas ou falhar graciosamente , seja funcionando em um nível reduzido ou falhando completamente, o faz de uma maneira que protege pessoas, propriedades ou dados contra ferimentos, danos, intrusão ou divulgação. Em computadores, um programa pode ser à prova de falhas executando uma saída normal (em oposição a uma falha descontrolada) para evitar a corrupção de dados após ocorrer um erro. Uma distinção semelhante é feita entre "falhar bem" e " falhar mal ".

Fail-mortal é a estratégia oposta, que pode ser usada em sistemas de armas projetados para matar ou ferir alvos, mesmo que parte do sistema seja danificada ou destruída.

Um sistema que é projetado para experimentar degradação graciosa , ou para falhar soft (usado em computação, semelhante ao "fail safe" [12] ) opera em um nível reduzido de desempenho após algumas falhas de componentes. Por exemplo, um edifício pode operar iluminação em níveis reduzidos e elevadores em velocidades reduzidas se a energia da rede falhar, em vez de prender as pessoas completamente no escuro ou continuar operando com potência total. Na computação, um exemplo de degradação graciosa é que, se a largura de banda de rede insuficiente estiver disponível para transmitir um vídeo online, uma versão de resolução mais baixa pode ser transmitida no lugar da versão de alta resolução. Melhoria progressivaé um exemplo em computação, onde as páginas da Web estão disponíveis em um formato funcional básico para navegadores da Web mais antigos, de tela pequena ou de capacidade limitada, mas em uma versão aprimorada para navegadores capazes de lidar com tecnologias adicionais ou que tenham uma tela maior disponível.

Em sistemas de computador tolerantes a falhas , os programas considerados robustos são projetados para continuar a operação apesar de um erro, exceção ou entrada inválida, em vez de travar completamente. A fragilidade do software é o oposto da robustez. Redes resilientes continuam a transmitir dados apesar da falha de alguns links ou nós; edifícios e infraestrutura resilientes também devem evitar falhas completas em situações como terremotos, inundações ou colisões.

Um sistema com alta transparência de falhas alertará os usuários de que ocorreu uma falha de um componente, mesmo que continue a operar com desempenho total, para que a falha possa ser reparada ou a falha completa iminente seja antecipada. [13] Da mesma forma, um componente fail-fast é projetado para relatar no primeiro ponto de falha, em vez de permitir que componentes downstream falhem e gerem relatórios então. Isso permite um diagnóstico mais fácil do problema subjacente e pode impedir a operação inadequada em um estado quebrado.

Condição de falha única [ editar ]

Uma condição de falha única é uma situação em que um meio de proteção contra um perigo está defeituoso. Se uma única condição de falha resultar inevitavelmente em outra condição de falha única, as duas falhas são consideradas como uma única condição de falha. [14] Uma fonte oferece o seguinte exemplo:

Uma condição de falha única é uma condição em que um único meio de proteção contra riscos no equipamento está com defeito ou uma única condição externa anormal está presente, por exemplo, curto-circuito entre as partes energizadas e a parte aplicada. [15]

Critérios [ editar ]

Fornecer design tolerante a falhas para cada componente normalmente não é uma opção. A redundância associada traz uma série de penalidades: aumento de peso, tamanho, consumo de energia, custo, bem como tempo para projetar, verificar e testar. Portanto, várias opções devem ser examinadas para determinar quais componentes devem ser tolerantes a falhas: [16]

  • Quão crítico é o componente? Em um carro, o rádio não é crítico, então este componente tem menos necessidade de tolerância a falhas.
  • Qual a probabilidade de o componente falhar? Alguns componentes, como o eixo de transmissão de um carro, provavelmente não falharão, portanto, não é necessária tolerância a falhas.
  • Quão caro é tornar o componente tolerante a falhas? Exigir um motor de carro redundante, por exemplo, provavelmente seria muito caro, tanto economicamente quanto em termos de peso e espaço, para ser considerado.

Um exemplo de componente que passa em todos os testes é o sistema de retenção de ocupantes de um carro. Embora normalmente não pensemos no sistema de retenção do ocupante principal , é a gravidade . Se o veículo capotar ou sofrer forças G severas, esse método primário de retenção de ocupantes pode falhar. Conter os ocupantes durante um acidente desse tipo é absolutamente crítico para a segurança, por isso passamos no primeiro teste. Acidentes com ejeção de ocupantes eram bastante comuns antes dos cintos de segurança , então passamos no segundo teste. O custo de um método de retenção redundante como cintos de segurança é bastante baixo, tanto economicamente quanto em termos de peso e espaço, por isso passamos no terceiro teste. Portanto, adicionar cintos de segurança em todos os veículos é uma excelente ideia. Outros "sistemas de retenção suplementares", comoairbags , são mais caros e, portanto, passam nesse teste por uma margem menor.

Outro exemplo excelente e de longo prazo desse princípio sendo colocado em prática é o sistema de freios: embora os mecanismos de freio reais sejam críticos, eles não são particularmente propensos a falhas repentinas (em vez de progressivos) e, em qualquer caso, são necessariamente duplicados para permitir aplicação uniforme e equilibrada da força de frenagem em todas as rodas. Também seria proibitivamente caro duplicar ainda mais os componentes principais e eles adicionariam um peso considerável. No entanto, os sistemas igualmente críticos para acionar os freios sob controle do motorista são inerentemente menos robustos, geralmente usando um cabo (pode enferrujar, esticar, emperrar, quebrar) ou fluido hidráulico (pode vazar, ferver e desenvolver bolhas, absorver água e, assim, perder eficácia ). Assim, na maioria dos carros modernos, o circuito de freio hidráulico do pedal é dividido diagonalmente para fornecer dois pontos de falha menores, a perda de apenas reduzir a potência de frenagem em 50% e não causar tanto desequilíbrio perigoso da força de frenagem quanto uma divisão reta frente-trás ou esquerda-direita, e se o circuito hidráulico falhar completamente (uma ocorrência relativamente muito rara), há uma proteção contra falhas na forma de freio de estacionamento acionado por cabo que opera os freios traseiros relativamente fracos, mas ainda pode parar o veículo com segurança em conjunto com a transmissão/frenagem do motor, desde que as demandas estejam alinhadas com o fluxo normal de tráfego . A combinação cumulativamente improvável de falha total do freio de pé com a necessidade de frenagem brusca em uma emergência provavelmente resultará em uma colisão, mas ainda em velocidade mais baixa do que teria sido o caso. há uma proteção contra falhas na forma do freio de estacionamento acionado por cabo que opera os freios traseiros relativamente fracos, mas ainda pode parar o veículo com segurança em conjunto com a transmissão / frenagem do motor, desde que as demandas estejam alinhadas com fluxo normal de tráfego. A combinação cumulativamente improvável de falha total do freio de pé com a necessidade de frenagem brusca em uma emergência provavelmente resultará em uma colisão, mas ainda em velocidade mais baixa do que teria sido o caso. há uma proteção contra falhas na forma do freio de estacionamento acionado por cabo que opera os freios traseiros relativamente fracos, mas ainda pode parar o veículo com segurança em conjunto com a transmissão / frenagem do motor, desde que as demandas estejam alinhadas com fluxo normal de tráfego. A combinação cumulativamente improvável de falha total do freio de pé com a necessidade de frenagem brusca em uma emergência provavelmente resultará em uma colisão, mas ainda em velocidade mais baixa do que teria sido o caso.

Em comparação com o freio de serviço acionado por pedal, o freio de estacionamento em si é um item menos crítico e, a menos que esteja sendo usado como backup único para o freio de pé, não causará perigo imediato se for considerado inoperante no momento da aplicação. Portanto, não há redundância em si (e normalmente usa um sistema de acionamento por cabo mais barato, mais leve, mas menos resistente), e pode ser suficiente, se isso acontecer em uma colina, usar o freio de pé para manter momentaneamente o veículo parado , antes de sair para encontrar um pedaço plano de estrada para parar. Alternativamente, em declives rasos, a transmissão pode ser mudada para Park, Reverse ou First Gear, e a trava da transmissão / compressão do motor usada para mantê-la estacionária, pois não há necessidade de incluir a sofisticação para primeiro pará-la .

Em motocicletas, um nível semelhante de segurança contra falhas é fornecido por métodos mais simples; em primeiro lugar os sistemas de freio dianteiro e traseiro sendo totalmente separados, independentemente do seu método de acionamento (que pode ser cabo, haste ou hidráulico), permitindo que um falhe completamente enquanto o outro não é afetado. Em segundo lugar, o freio traseiro é relativamente forte em comparação com seu primo automotivo, mesmo sendo um disco potente em modelos esportivos, embora a intenção usual seja que o sistema dianteiro forneça a grande maioria da força de frenagem; como o peso total do veículo é mais central, o pneu traseiro é geralmente maior e mais aderente, e o piloto pode se inclinar para trás para colocar mais peso nele, permitindo assim que mais força de frenagem seja aplicada antes que a roda trave. Em máquinas de classe utilitária mais baratas e lentas,

Requisitos [ editar ]

As características básicas da tolerância a falhas requerem:

  1. Nenhum ponto único de falha – Se um sistema apresentar uma falha, ele deve continuar operando sem interrupção durante o processo de reparo.
  2. Isolamento de falha para o componente com falha – Quando ocorre uma falha, o sistema deve ser capaz de isolar a falha para o componente com falha. Isso requer a adição de mecanismos dedicados de detecção de falhas que existem apenas para fins de isolamento de falhas. A recuperação de uma condição de falha requer a classificação da falha ou do componente com falha. O Instituto Nacional de Padrões e Tecnologia (NIST) categoriza as falhas com base na localidade, causa, duração e efeito. [ onde? ] [ esclarecimento necessário ]
  3. Contenção de falhas para evitar a propagação da falha – Alguns mecanismos de falha podem fazer com que um sistema falhe ao propagar a falha para o resto do sistema. Um exemplo desse tipo de falha é o "transmissor desonesto" que pode inundar a comunicação legítima em um sistema e causar uma falha geral do sistema. São necessários firewalls ou outros mecanismos que isolam um transmissor ou componente defeituoso para proteger o sistema.
  4. Disponibilidade de modos de reversão [ esclarecimento necessário ]

Além disso, os sistemas tolerantes a falhas são caracterizados em termos de interrupções de serviço planejadas e interrupções de serviço não planejadas. Geralmente, eles são medidos no nível do aplicativo e não apenas no nível do hardware. A figura de mérito é chamada de disponibilidade e é expressa em porcentagem. Por exemplo, um sistema de cinco noves forneceria estatisticamente 99,999% de disponibilidade.

Sistemas tolerantes a falhas são tipicamente baseados no conceito de redundância.

Técnicas de tolerância a falhas [ editar ]

A pesquisa sobre os tipos de tolerâncias necessários para sistemas críticos envolve uma grande quantidade de trabalho interdisciplinar. Quanto mais complexo o sistema, mais cuidadosamente todas as interações possíveis devem ser consideradas e preparadas. Considerando a importância dos sistemas de alto valor nos transportes, serviços públicos e militares, o campo de tópicos que tocam na pesquisa é muito amplo: pode incluir assuntos tão óbvios como modelagem e confiabilidade de software, ou design de hardware , até elementos misteriosos como modelos estocásticos , teoria dos grafos , lógica formal ou excludente, processamento paralelo , transmissão remota de dados e muito mais. [17]

Replicação [ editar ]

Os componentes sobressalentes abordam a primeira característica fundamental da tolerância a falhas de três maneiras:

  • Replicação : Fornecer várias instâncias idênticas do mesmo sistema ou subsistema, direcionando tarefas ou solicitações para todas elas em paralelo e escolhendo o resultado correto com base em um quorum ;
  • Redundância : Fornecer várias instâncias idênticas do mesmo sistema e alternar para uma das instâncias restantes em caso de falha ( failover );
  • Diversidade: Fornecer várias implementações diferentes da mesma especificação e usá-las como sistemas replicados para lidar com erros em uma implementação específica.

Todas as implementações de RAID , matriz redundante de discos independentes , exceto RAID 0, são exemplos de dispositivo de armazenamento tolerante a falhas que utiliza redundância de dados .

Uma máquina tolerante a falhas lockstep usa elementos replicados operando em paralelo. A qualquer momento, todas as replicações de cada elemento devem estar no mesmo estado. As mesmas entradas são fornecidas para cada replicação e as mesmas saídas são esperadas. As saídas das replicações são comparadas usando um circuito de votação. Uma máquina com duas replicações de cada elemento é denominada redundante modular dupla (DMR). O circuito de votação só pode detectar uma incompatibilidade e a recuperação depende de outros métodos. Uma máquina com três replicações de cada elemento é denominada redundante modular tripla(TMR). O circuito de votação pode determinar qual replicação está com erro quando um voto de dois para um é observado. Nesse caso, o circuito de votação pode emitir o resultado correto e descartar a versão incorreta. Depois disso, assume-se que o estado interno da replicação errônea é diferente dos outros dois, e o circuito de votação pode mudar para um modo DMR. Este modelo pode ser aplicado a qualquer número maior de repetições.

Máquinas tolerantes a falhas Lockstep são mais facilmente tornadas totalmente síncronas , com cada porta de cada replicação fazendo a mesma transição de estado na mesma borda do relógio, e os relógios para as replicações estando exatamente em fase. No entanto, é possível construir sistemas lockstep sem este requisito.

Colocar as replicações em sincronia requer tornar seus estados internos armazenados iguais. Eles podem ser iniciados a partir de um estado inicial fixo, como o estado de reinicialização. Como alternativa, o estado interno de uma réplica pode ser copiado para outra réplica.

Uma variante do DMR é par e sobressalente . Dois elementos replicados operam em sincronia como um par, com um circuito de votação que detecta qualquer incompatibilidade entre suas operações e emite um sinal indicando que há um erro. Outro par opera exatamente da mesma maneira. Um circuito final seleciona a saída do par que não proclama que está com erro. Par-and-spare requer quatro réplicas em vez de três de TMR, mas tem sido usado comercialmente.

Computação alheia a falhas [ editar ]

A computação alheia a falhas é uma técnica que permite que os programas de computador continuem em execução apesar dos erros . [18] A técnica pode ser aplicada em diferentes contextos. Primeiro, ele pode lidar com leituras de memória inválidas retornando um valor fabricado para o programa, [19] que por sua vez, faz uso do valor fabricado e ignora o valor de memória anterior que tentou acessar, isso é um grande contraste com os verificadores de memória típicos , que informam o programa sobre o erro ou abortam o programa. Em segundo lugar, pode ser aplicado a exceções onde alguns blocos catch são escritos ou sintetizados para capturar exceções inesperadas. [20]Além disso, acontece que a execução é modificada várias vezes seguidas, para evitar falhas em cascata. [21]

A abordagem tem custos de desempenho: como a técnica reescreve o código para inserir verificações dinâmicas de validade de endereço, o tempo de execução aumentará de 80% a 500%. [22]

Pastoreio de recuperação [ editar ]

O pastoreio de recuperação é uma técnica leve para permitir que programas de software se recuperem de erros fatais, como desreferência de ponteiro nulo e divisão por zero. [23] Comparando com a técnica de computação inconsciente de falhas, o pastoreio de recuperação funciona diretamente no binário do programa compilado e não precisa recompilar para programar.

Ele usa a estrutura de instrumentação binária just-in-time Pin . Ele se conecta ao processo do aplicativo quando ocorre um erro, repara a execução, rastreia os efeitos do reparo à medida que a execução continua, contém os efeitos do reparo no processo do aplicativo e se desvincula do processo depois que todos os efeitos do reparo são liberados do estado do processo. Não interfere com a execução normal do programa e, portanto, incorre em sobrecarga insignificante. [23] Para 17 de 18 erros de desreferência nula e divisão por zero coletados sistematicamente no mundo real, uma implementação de protótipo permite que o aplicativo continue a executar para fornecer saída e serviço aceitáveis ​​a seus usuários nas entradas que desencadeiam erros. [23]

Disjuntor [ editar ]

O padrão de projeto do disjuntor é uma técnica para evitar falhas catastróficas em sistemas distribuídos.

Redundância [ editar ]

Redundância é o fornecimento de recursos funcionais que seriam desnecessários em um ambiente livre de falhas. [24] Isso pode consistir em componentes de backup que "acionam" automaticamente se um componente falhar. Por exemplo, grandes caminhões de carga podem perder um pneu sem grandes consequências. Eles têm muitos pneus, e nenhum pneu é crítico (com exceção dos pneus dianteiros, que são usados ​​para dirigir, mas geralmente carregam menos carga, cada um e no total, do que os outros quatro a 16, então são menos propensos a falhar ). A ideia de incorporar redundância para melhorar a confiabilidade de um sistema foi iniciada por John von Neumann na década de 1950. [25]

Dois tipos de redundância são possíveis: [26] redundância de espaço e redundância de tempo. A redundância de espaço fornece componentes, funções ou itens de dados adicionais que são desnecessários para uma operação sem falhas. A redundância de espaço é ainda classificada em hardware, software e redundância de informações, dependendo do tipo de recursos redundantes adicionados ao sistema. Na redundância de tempo, a computação ou transmissão de dados é repetida e o resultado é comparado a uma cópia armazenada do resultado anterior. A terminologia atual para esse tipo de teste é chamada de 'Teste de tolerância a falhas em serviço ou ISFTT para abreviar.

Desvantagens [ editar ]

As vantagens do design tolerante a falhas são óbvias, enquanto muitas de suas desvantagens não são:

  • Interferência na detecção de falhas no mesmo componente. Para continuar o exemplo de veículo de passageiros acima, com qualquer um dos sistemas tolerantes a falhas, pode não ser óbvio para o motorista quando um pneu foi furado. Isso geralmente é tratado com um "sistema automatizado de detecção de falhas" separado. No caso do pneu, um monitor de pressão de ar detecta a perda de pressão e avisa o motorista. A alternativa é um "sistema manual de detecção de falhas", como inspecionar manualmente todos os pneus em cada parada.
  • Interferência na detecção de falhas em outro componente. Outra variação desse problema é quando a tolerância a falhas em um componente impede a detecção de falhas em um componente diferente. Por exemplo, se o componente B executa alguma operação com base na saída do componente A, a tolerância a falhas em B pode ocultar um problema com A. Se o componente B for alterado posteriormente (para um projeto menos tolerante a falhas), o sistema poderá falhar repentinamente, fazendo parecer que o novo componente B é o problema. Somente depois que o sistema tiver sido cuidadosamente examinado, ficará claro que a raiz do problema está realmente no componente A.
  • Redução da prioridade de correção de falhas. Mesmo que o operador esteja ciente da falha, ter um sistema tolerante a falhas provavelmente reduzirá a importância de reparar a falha. Se as falhas não forem corrigidas, isso eventualmente levará à falha do sistema, quando o componente tolerante a falhas falhar completamente ou quando todos os componentes redundantes também falharem.
  • Dificuldade do teste. Para certos sistemas críticos tolerantes a falhas, como um reator nuclear , não há uma maneira fácil de verificar se os componentes de backup estão funcionando. O exemplo mais infame disso é Chernobyl , onde os operadores testaram o resfriamento de backup de emergência desabilitando o resfriamento primário e secundário. O backup falhou, resultando em um colapso do núcleo e liberação maciça de radiação.
  • Custo. Tanto os componentes tolerantes a falhas quanto os componentes redundantes tendem a aumentar o custo. Isso pode ser um custo puramente econômico ou pode incluir outras medidas, como peso. As naves tripuladas , por exemplo, têm tantos componentes redundantes e tolerantes a falhas que seu peso aumenta drasticamente em relação aos sistemas não tripulados, que não exigem o mesmo nível de segurança.
  • Componentes inferiores. Um projeto tolerante a falhas pode permitir o uso de componentes inferiores, que de outra forma tornariam o sistema inoperante. Embora essa prática tenha o potencial de mitigar o aumento de custo, o uso de vários componentes inferiores pode reduzir a confiabilidade do sistema a um nível igual ou até pior do que um sistema não tolerante a falhas comparável.

Termos relacionados [ editar ]

Existe uma diferença entre tolerância a falhas e sistemas que raramente apresentam problemas. Por exemplo, os sistemas de barra transversal da Western Electric tinham taxas de falha de duas horas por quarenta anos e, portanto, eram altamente resistentes a falhas . Mas quando ocorreu uma falha, eles ainda pararam de operar completamente e, portanto, não eram tolerantes a falhas .

Veja também [ editar ]

Referências [ editar ]

  1. ^ Adaptive Fault Tolerance and Graceful Degradation , Oscar González et al., 1997, University of Massachusetts - Amherst
  2. ^ Johnson, BW (1984). " Sistemas Baseados em Microprocessadores Tolerantes a Falhas ", IEEE Micro, vol. 4, não. 6, págs. 6–21
  3. ^ a b c Daniel P. Siewiorek; C. Gordon Bell; Allen Newell (1982). Estruturas de Computadores: Princípios e Exemplos . McGraw-Hill . ISBN 0-07-057302-6.
  4. ^ Algirdas Avižienis; George C. Gilley; Francis P. Mathur; David A. Rennels; John A. Rohr; David K. Rubin. "O computador STAR (autoteste e reparo): uma investigação da teoria e prática do projeto de computador tolerante a falhas" (PDF) .
  5. ^ Randell, Brian ; Lee, PA; Treleaven, PC (junho de 1978). "Questões de Confiabilidade no Projeto de Sistemas Computacionais" . Pesquisas de Computação ACM . 10 (2): 123–165. doi : 10.1145/356725.356729 . ISSN 0360-0300 . S2CID 16909447 .  
  6. ^ PJ Denning (dezembro de 1976). "Sistemas operacionais tolerantes a falhas" . Pesquisas de Computação ACM . 8 (4): 359–389. doi : 10.1145/356678.356680 . ISSN 0360-0300 . S2CID 207736773 .  
  7. ^ Theodore A. Linden (dezembro de 1976). "Estruturas de Sistema Operacional para Suportar Segurança e Software Confiável" . Pesquisas de Computação ACM . 8 (4): 409–445. doi : 10.1145/356678.356682 . hdl : 2027/mdp.39015086560037 . ISSN 0360-0300 . S2CID 16720589 .  
  8. ^ Ray Holt. "O F14A Central Air Data Computer e a LSI Technology State-of-the-Art em 1968" .
  9. ^ Computação tolerante a falhas em design de computador Neilforoshan, MR Journal of Computing Sciences in Colleges arquivo Volume 18, Edição 4 (abril de 2003) Páginas: 213 – 220, ISSN 1937-4771 
  10. ^ "Por que seu site deve funcionar sem JavaScript" . Comunidade DEV . Recuperado 2021-05-16 .
  11. ^ Fairfax, Zackerie (2020-11-28). "O desligamento do Twitter legado significa que você não pode mais tweetar do 3DS" . ScreenRant . Recuperado 2021-07-01 .{{cite web}}: CS1 maint: url-status ( link )
  12. ^ Stallings, W (2009): Sistemas operacionais. Internals and Design Principles , sexta edição
  13. ^ Thampi, Sabu M. (2009-11-23). "Introdução aos Sistemas Distribuídos". arXiv : 0911.4395 [ cs.DC ].
  14. ^ "Controle" . Grouper.ieee.org . Arquivado a partir do original em 1999-10-08 . Recuperado 2016-04-06 .
  15. ^ Baha Al-Shaikh, Simon G. Stacey, Essentials of Equipment in Anesthesia, Critical Care, and Peri-Operative Medicine (2017), p. 247.
  16. ^ Dubrova, E. (2013). "Design Tolerante a Falhas", Springer, 2013, ISBN 978-1-4614-2112-2 
  17. ^ Avaliação da confiabilidade de algumas arquiteturas de computador tolerantes a falhas . Springer-Verlag. Novembro de 1980. ISBN 978-3-540-10274-8.
  18. ^ Herzberg, Amir; Shulman, Haya (2012). "Computação de duas partes alheia e justa auxiliada pelo servidor" . 2012 Sétima Conferência Internacional sobre Disponibilidade, Confiabilidade e Segurança . IEEE: 75–84. doi : 10.1109/ares.2012.28 . ISBN 978-1-4673-2244-7. S2CID  6579295 .
  19. ^ Rigger, Manuel; Pekarek, Daniel; Mössenböck, Hanspeter (2018), "Context-Aware Failure-Oblivious Computing as a Means of Prevent Buffer Overflows" , Network and System Security , Cham: Springer International Publishing, pp. 376–390, arXiv : 1806.09026 , doi : 10.1007/978 -3-030-02744-5_28 , ISBN 978-3-030-02743-8, recuperado 2020-10-07
  20. ^ Zhang, Longo; Monperrus, Martin (2019). "TripleAgent: monitoramento, perturbação e esquecimento de falhas para melhoria de resiliência automatizada em aplicativos Java" . 2019 IEEE 30th International Symposium on Software Reliability Engineering (ISSRE) . Berlim, Alemanha: IEEE: 116–127. arXiv : 1812.10706 . doi : 10.1109/ISSRE.2019.00021 . ISBN 978-1-7281-4982-0. S2CID  57189195 .
  21. ^ Durieux, Thomas; Hamadi, Youssef; Yu, Zhongxing; Baudry, Benoit; Monperrus, Martin (2018). "Exploração exaustiva do espaço de pesquisa de computação alheia a falhas". 2018 IEEE 11th International Conference on Software Testing, Verification and Validation (ICST) . págs. 139-149. arXiv : 1710.09722 . doi : 10.1109/ICST.2018.00023 . ISBN 978-1-5386-5012-7. S2CID  4304123 .
  22. ^ Keromytis, Angelos D. (2007), "Caracterizando Sistemas de Autocura de Software" , em Gorodetski, Vladimir I.; Kotenko, Igor; Skormin , Victor A. ( eds . ) 978-3-540-73985-2
  23. ^ a b c Longo, Ventilador; Sidiroglou-Douskos, Stelios; Rinard, Martin (2014). "Reparação e contenção automática de erros de tempo de execução via pastoreio de recuperação". Anais da 35ª Conferência ACM SIGPLAN sobre Projeto e Implementação de Linguagens de Programação . PLDI '14'. Nova York, NY, EUA: ACM. pp. 227-238. doi : 10.1145/2594291.2594337 . ISBN 978-1-4503-2784-8. S2CID  6252501 .
  24. ^ Laprie, JC (1985). " Computação Confiável e Tolerância a Falhas: Conceitos e Terminologia ", Anais do 15º Simpósio Internacional de Computação Tolerante a Falhas (FTSC-15), pp. 2–11
  25. ^ von Neumann, J. (1956). " Probabilistic Logics and Synthesis of Reliable Organisms from Unreliable Components ", in Automata Studies, eds. C. Shannon e J. McCarthy, Princeton University Press, pp. 43-98
  26. ^ Avizienis, A. (1976). " Sistemas Tolerantes a Falhas ", IEEE Transactions on Computers, vol. 25, não. 12, pp. 1304-1312