Qual é a diferença entre robustez e tolerância a falhas?


12

Sistemas / programas / algoritmos distribuídos / ... são frequentemente descritos com o predicado robusto ou tolerante a falhas .

Qual é a diferença?


Detalhes:

Quando pesquiso no Google + robusto + "tolerante a falhas", recebo apenas duas ocorrências, ambas inúteis.

Quando pesquiso os termos no Google, encontro muitos artigos com ambos os termos no título. Infelizmente, eles não definem precisamente os termos :( Mas, como eles usam os dois termos, parece que nenhum deles implica o outro.



Sim, essa foi uma das primeiras coisas que li para descobrir o significado delas. Infelizmente, ambos descrevem a mesma coisa em um nível abstrato, sem se referir ao outro. É por isso que estou perguntando aqui.
DaveFar

Respostas:


33

Ambos descrevem a consistência do comportamento de um aplicativo, mas "robustez" descreve a resposta de um aplicativo à sua entrada , enquanto "tolerância a falhas" descreve a resposta de um aplicativo ao seu ambiente .

Um aplicativo é robusto quando pode trabalhar de forma consistente com dados inconsistentes. Por exemplo: um aplicativo de mapas é robusto quando pode analisar endereços em vários formatos com vários erros de ortografia e retornar um local útil. Um music player é robusto quando pode continuar decodificando um MP3 depois de encontrar um quadro malformado. Um editor de imagens é robusto quando pode modificar uma imagem com metadados EXIF ​​incorporados que talvez não reconheça - especialmente se puder fazer alterações na imagem sem destruir os dados EXIF.

Um aplicativo é tolerante a falhas quando pode funcionar de forma consistente em um ambiente inconsistente. Um aplicativo de banco de dados é tolerante a falhas quando pode acessar um fragmento alternativo quando o principal não está disponível. Um aplicativo da Web é tolerante a falhas quando pode continuar manipulando solicitações do cache, mesmo quando um host da API está inacessível. Um subsistema de armazenamento é tolerante a falhas quando pode retornar resultados calculados a partir da paridade quando um membro do disco está offline.

Nos dois casos, espera-se que o aplicativo permaneça estável, se comporte de maneira uniforme, preserve a integridade dos dados e forneça resultados úteis, mesmo quando um erro for encontrado. Porém, ao avaliar a robustez, você pode encontrar critérios que envolvem dados, enquanto que ao avaliar a tolerância a falhas, você encontra critérios que envolvem tempo de atividade.

Um não leva necessariamente ao outro. Um aplicativo de reconhecimento de voz móvel pode ser muito robusto, fornecendo uma capacidade extraordinária de reconhecer a fala de maneira consistente em uma variedade de sotaques regionais com enormes quantidades de ruído de fundo. Mas se for inútil sem uma conexão rápida de dados celulares, não é muito tolerante a falhas. Da mesma forma, um aplicativo de publicação na web pode ser imensamente tolerante a falhas, com várias redundâncias em todos os níveis, capaz de perder datacenters inteiros sem falhar, mas se ele eliminar uma tabela de usuário e travar na primeira vez que alguém se registrar com um apóstrofo em seu sobrenome , não é robusto.

Se você estiver procurando por literatura acadêmica para ajudar a descrever a distinção, procure domínios específicos que fazem uso de software, em vez de software em geral. A pesquisa de aplicativos distribuídos pode ser um terreno fértil para os critérios de tolerância a falhas, e o Google publicou algumas de suas pesquisas que podem ser relevantes. A pesquisa de modelagem de dados provavelmente aborda questões de robustez, pois os cientistas estão particularmente interessados ​​nas propriedades de robustez que produzem resultados reproduzíveis. Você provavelmente pode encontrar trabalhos descrevendo aplicativos estatísticos que podem ser úteis, como na modelagem climática, modelagem de propagação de RF ou sequenciamento de genoma. Você também encontrará engenheiros discutindo "design robusto" em coisas como sistemas de controle.

O whitepaper do Google File System descreve sua abordagem aos problemas de tolerância a falhas, que geralmente envolvem as suposições de que as falhas dos componentes são rotineiras e, portanto, o aplicativo deve se adaptar a elas:

Este projeto para uma classe na Rutgers suporta uma definição orientada para "falha de componente" de "tolerância a falhas":

Existem muitos documentos sobre "modelagem robusta XYZ", dependendo do campo que você investigar. A maioria descreverá seus critérios para "robusto" no resumo, e você descobrirá que tudo isso tem a ver com a maneira como o modelo lida com informações.

Este resumo de um cientista climático da NASA descreve a robustez como um critério para avaliar modelos climáticos:

Este artigo de um pesquisador do MIT examina aplicativos de protocolo sem fio, um domínio no qual a tolerância a falhas e a robustez se sobrepõem, mas os autores usam "robusto" para descrever aplicativos, protocolos e algoritmos, enquanto usam "tolerância a falhas" em referência à topologia e componentes:


0

Eu realmente gosto da resposta do @ johnnyb e endosso por suas definições nítidas. Mas, tendo trabalhado no campo por algumas décadas, reconheço outra maneira (muito menos formal e precisa) de que esses termos sejam frequentemente usados:

Como pontos informais ao longo de um continuum de "não confiável" para "perfeitamente confiável".

Não há sistema, aplicativo ou serviço que possa garantir que ele esteja sempre e sempre em funcionamento ("disponível continuamente" ou "disponível permanentemente"). "Tolerante a falhas" tem sido um substituto para "fizemos tudo humanamente possível com a tecnologia atual para garantir que isso continue funcionando corretamente".

Palavras como "robusto", "reforçado" e "altamente disponível" são usadas como marcos mais brandos em direção a essa meta de operação contínua. Eles refletem níveis crescentes de esforço, investimento e confiança.

Como esses termos são usados ​​informalmente, não há pedidos inteiramente canônicos. "Altamente disponível" é geralmente uma reivindicação forte, apenas em "resiliente a falhas" ou "tolerante a falhas". Mas é "endurecido" melhor que "robusto"? Ou vice-versa? Depende do contexto. Eles também são frequentemente usados ​​como declarações de marketing de produtos, com toda a gabarola e imprecisão intencional que isso implica.

Geralmente, as organizações que trabalham para atingir essas metas têm sua própria progressão acordada internamente, geralmente pelo menos aproximadamente ligada às metas / resultados do projeto e métricas externas, como "três noves" ou "seis noves".

O @johnnyb também aborda uma distinção crítica: a diferença entre o status de ativação / desativação da plataforma (disponibilidade), por um lado, e os atributos de algoritmo, aplicativo ou serviço, por outro.

Eu digo "atributos" porque existem muitos: desempenho, correção e imperturbabilidade são apenas alguns dos principais. Um sistema está significativamente disponível e correto se estiver operando com apenas 10% do desempenho avaliado? Não de acordo com os empresários, se for a estação movimentada! Não existe uma grande virtude em um sistema que realmente nunca cai, mas que também fornece respostas incorretas a maior parte do tempo. Por fim, um sistema de análise de dados está funcionando "certo" se uma variação de 0,2% na entrada fornecer uma resposta diferente de 3,400%? Talvez ... mas vai parecer um modelo bastante caprichoso e insatisfatório para muitos. Não analisarei a lista estendida de atributos, mas a integridade dos dados, a segurança dos dados, a privacidade dos dados e outros problemas de correção e segurança são preocupações comuns. (Se você é uma organização ou agência governamental muito grande, você se preocupa cada vez mais em preservar esses atributos, não apenas por alguns anos ou ciclos de produtos, mas por décadas ou possivelmente séculos. Ainda não existem arquiteturas, processos ou abordagens comprovadas para fazer isso.)

Essas possíveis variações entre "em operação" e "fazer o que queremos" - e como especificar, medir e impedir tais variações - são um desafio há muito tempo, mesmo depois que a redundância, o fortalecimento e outras etapas em direção a falhas tolerância foram tomadas. E no uso informal, "correr" e várias formas de "correr como eu quero" são conflitantes, sem todas as distinções claras que se deseja.

Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.