Computação Orientada à Recuperação (ROC) -Motivação, Definição, Técnicas e Estudos de Caso

David Patterson, Aaron Brown, Pete Broadwell, George Candea, Mike Chen, James Cutler,Patricia Enriquez, Armando Fox=, Emre Kiciman , Matthew Merzbacher, David Oppenheimer, Naveen Sastry, William Tetzlaff, Jonathan Traupman e Noah Treuhaft Divisão de Ciência da Computação, Universidade da Califórnia em Berkeley (a menos que indicado) *Departamento de Ciência da Computação, Mills College Departamento de Ciência da Computação, Universidade de Stanford Pesquisa IBM, Almaden

Autor de contato: David A. Patterson, patterson@cs.berkeley.edu

Resumo

É hora de declarar vitória para nossa agenda de pesquisa orientada para o desempenho. Quatro ordens de magnitude de aumento no desempenho desde o primeiro ASPLOS significam que poucos fora da comunidade de pesquisa de CS&E acreditam que a velocidade é o problema de hardware e software de computador. Os sistemas atuais travam e congelam com tanta frequência que as pessoas se tornam violentas.1 A descamação mais rápida não deveria ser o legado do século 21. A Computação Orientada à Recuperação (ROC) assume a perspectiva de que falhas de hardware, bugs de software e erros do operador são fatos a serem enfrentados, não problemas a serem resolvidos. Concentrando-se no Tempo Médio de Reparo (MTTR) em vez do Tempo Médio de Falha (MTTF), o ROC reduz o tempo de recuperação desses fatos e, portanto, oferece maior disponibilidade. Como grande parte da administração do sistema está lidando com falhas, o ROC também pode reduzir o custo total de propriedade. A redução de uma a duas ordens de magnitude no custo nos últimos 20 anos significa que o preço de compra de hardware e software é agora uma pequena parte do custo total de propriedade. Além de fornecer a motivação, definição e técnicas do ROC, apresentamos dados quantitativos de falhas para sites da Internet e o sistema de telefonia pública, que sugerem que o erro do operador é uma das principais causas de interrupções. Também apresentamos resultados do uso de seis técnicas ROC em cinco estudos de caso: particionamento de hardware e inserção de falhas em um cluster personalizado; inserção de falhas de software por meio de uma biblioteca, o que mostra falta de graça quando os aplicativos enfrentam falhas; diagnóstico automatizado de falhas em rotinas J2EE sem antes analisar a estrutura do software; uma redução de cinco vezes no tempo para recuperar o software de uma estação terrestre de satélite usando reinicialização parcial de baixa granularidade; e desenho de um serviço de e-mail que suporte desfazer pelo operador. Se adotarmos disponibilidade e manutenibilidade, os sistemas do futuro poderão competir em desempenho de recuperação em vez de desempenho SPEC e em custo total de propriedade em vez de preço do sistema. Essa mudança nos marcos pode restaurar nosso orgulho nas arquiteturas e sistemas operacionais que criamos

1. Motivação

O foco principal de pesquisadores e desenvolvedores nos 20 anos desde a primeira conferência ASPLOS tem sido o desempenho, e esse esforço obstinado rendeu uma melhoria de 12.000 vezes [HP02]. A chave para esse sucesso tem sido os benchmarks, que medem o progresso e recompensam os vencedores. Os benchmarks permitem que os desenvolvedores avaliem e aprimorem seus projetos, ajudem os clientes a avaliar novos produtos de maneira justa, permitam que os pesquisadores meçam novas ideias e ajudem na publicação de pesquisas ajudando os revisores a avaliá-las. Não surpreendentemente, esse foco único no desempenho negligenciou outros aspectos da computação: confiabilidade, segurança, privacidade e custo total de propriedade, para citar alguns. Por exemplo, o custo de propriedade é amplamente divulgado como sendo de 5 a 10 vezes o custo do hardware e do software. A Figura 1 mostra as mesmas proporções para sistemas Linux e UNIX: a média de sistemas operacionais UNIX em hardware RISC é de 3:1 a 15:1, enquanto o Linux em 80x86 aumenta para 7:1 a 19:1.

Figura 1. Relação entre o Custo de Propriedade de Três Anos e o Custo de Compra de Hardware/Software para sistemas x86/Linix e RISC/Unix [Gillen 2002]. Esses resultados são normalizados para o Custo Total de Propriedade por mil usuários. Para coletar esses dados, no segundo semestre de 2001 a IDC entrevistou 142 empresas. Observe que vários custos normalmente associados à propriedade não foram incluídos: espaço, energia, mídia, comunicações, contratos de suporte de HW/SW e tempo de inatividade. As empresas tiveram vendas médias de US$ 2,4 bilhões/ano e os sites tinham de 3 a 12 servidores suportando 1.100 a 7.600 usuários/site. Os sites foram divididos em dois serviços: Internet/Intranet (firewall, serviço Web, Web caching, B2B, B2C) e Colaborativo (calendário, e-mail, arquivo compartilhado, banco de dados compartilhado).

Tais resultados são fáceis de explicar em retrospecto. Processadores mais rápidos e memórias maiores significam mais usuários nesses sistemas, e é provável que o custo de administração do sistema seja mais uma função do número de usuários do que do preço do sistema. Várias tendências reduziram o preço de compra de hardware e software: Lei de Moore, hardware de PC comum, clusters e software de código aberto. Além disso, os salários dos administradores de sistema aumentaram enquanto os preços caíram, inevitavelmente levando hardware e software em 2002 a ser um pequena fração do custo total de propriedade.

O foco único no desempenho também afetou a disponibilidade e o custo da indisponibilidade. Apesar das campanhas de marketing prometerem 99,999% de disponibilidade, servidores bem gerenciados hoje atingem de 99,9% a 99%, ou 8 a 80 horas de inatividade por ano. Cada hora pode ser cara, de US$ 200.000 por hora para um ISP como a Amazon a US$ 6.000.000 por hora para uma corretora de ações [Kembe00].

Figura 2. Porcentagem de chamadas bloqueadas em 2000 por causa: humano, hardware, software e sobrecarga. Representando mais de 200 interrupções telefônicas nos EUA que afetaram pelo menos 30.000 clientes ou duraram 30 minutos, conforme exigido pela FCC. Em vez de relatar interrupções, as centrais telefônicas registram o número de tentativas de chamadas bloqueadas durante uma interrupção, o que é uma medida atraente de falha.

As razões para o fracasso não são o que você pode pensar. A Figura 2 mostra as falhas da Rede Telefônica Pública Comutada. As operadoras são responsáveis por cerca de 60% dos problemas, com hardware em cerca de 20%, software em cerca de 10% e linhas telefônicas sobrecarregadas em outros 10%. A Tabela 1 mostra porcentagens de interrupções para três serviços da Internet: um site de alto tráfego, um site de serviços online e um site de conteúdo global. Essas medidas mostram que as operadoras voltam a ser as principais causas de interrupções, sendo as camadas problemáticas o front end, com sua grande fração de recursos, ou a rede, com sua natureza distribuída e sua dificuldade de diagnóstico; observe que quase todas as falhas desconhecidas estão associadas a rede

Tabela 1. Porcentagem de falhas para três sites da Internet, por tipo e camada. Os três sites são um site de serviço online, um site de conteúdo global e um site de leitura principalmente. (Os dados com falha foram compartilhados apenas se garantimos o anonimato.) Todos os três serviços usam sistemas multicamadas com distribuição geográfica em uma WAN para aumentar a disponibilidade do serviço. O número de computadores varia de cerca de 500 para o Online Service a 5000 para o site Read Mostly. Apenas 20% dos nós estão no front-end do site de conteúdo, com 99% dos nós nos front-ends dos outros dois. Coletados em 2001, esses dados representam de seis semanas a seis meses de serviço

Não somos os únicos a apelar a novos desafios. Jim Gray [1999] pediu sistemas sem problemas, que podem se autogerenciar em grande parte enquanto fornecem um serviço para milhões de pessoas. Butler Lampson [1999] pediu sistemas que funcionem: eles atendem às suas especificações, estão sempre disponíveis, se adaptam ao ambiente em mudança, evoluem enquanto são executados e crescem sem limites práticos. Hennessy [1999] propôs que o novo alvo seria Disponibilidade, Manutenibilidade e Escalabilidade. A IBM Research [2001] anunciou recentemente um novo impulso na Computação Autonômica, pelo qual eles tentam tornar os sistemas mais inteligentes sobre o gerenciamento de si mesmos, em vez de apenas mais rápidos. Finalmente, Bill Gates [2002] definiu sistemas confiáveis como o novo alvo para seus desenvolvedores de sistemas operacionais, o que significa maior segurança, disponibilidade e privacidade.

O projeto Recovery Oriented Computing (ROC) apresenta uma perspectiva de como atingir os objetivos desses luminares. Nosso alvo são os serviços na rede, incluindo serviços de Internet como Yahoo e serviços corporativos como e-mail corporativo. As principais métricas para esses serviços são a disponibilidade e o custo total de propriedade, com os serviços de Internet também desafiados pela rápida expansão da demanda e implantação e pela rápida mudança de software.

A Seção 2 deste artigo examina outros campos, da análise de desastres à engenharia civil, para buscar ideias para orientar o projeto de tais sistemas. A Seção 3 apresenta as hipóteses do ROC de se concentrar na recuperação para tornar os sistemas mais confiáveis e menos dispendiosos. A Seção 4 lista seis técnicas que identificamos para orientar o ROC. A seção 5, a maior parte do artigo, mostra cinco casos que criamos para ajudar a avaliar esses princípios. A Seção 6 descreve o trabalho relacionado, e a Seção 7 conclui com uma discussão e direções futuras para o ROC.

2. Inspiração de outros campos

Como os sistemas atuais são rápidos, mas propensos a falhas, pensamos em tentar aprender com outros campos para novas direções e ideias. Eles são análise de desastres, análise de erro humano e projeto de engenharia civil

2.1 Desastres e Erros Latentes em Sistemas de Emergência

Charles Perrow [1990] analisou desastres, como o do reator nuclear em Three Mile Island (TMI) na Pensilvânia em 1979. Para tentar evitar desastres, os reatores nucleares são redundantes e dependem fortemente de “defesa em profundidade”, camadas de sistemas redundantes.

Os reatores são sistemas grandes, complexos e fortemente acoplados com muitas interações, por isso é muito difícil para os operadores entenderem o estado do sistema, seu comportamento ou o impacto potencial de suas ações. Lá também há erros na implementação e nos sistemas de medição e alerta que agravam a situação. Perrow aponta que em sistemas complexos fortemente acoplados coisas ruins acontecem, o que ele chama de acidentes normais. Ele diz que falhas múltiplas aparentemente impossíveis – que os cientistas da computação normalmente desconsideram como estatisticamente impossíveis – acontecem. Até certo ponto, esses são erros correlacionados, mas os erros latentes também se acumulam em um sistema aguardando um evento de ativação.

Ele também aponta que os sistemas de emergência são muitas vezes falhos. Por serem desnecessários para a operação do dia-a-dia, apenas uma emergência os testa, e erros latentes nos sistemas de emergência podem inutilizá-los. Na TMI, dois sistemas de alimentação de água de emergência tinham a válvula correspondente em cada sistema, um ao lado do outro, e foram ajustados manualmente na posição errada. Quando ocorreu a emergência, esses sistemas de backup falharam. Em última análise, o próprio edifício de contenção foi a última defesa, e eles finalmente conseguiram água suficiente para resfriar o reator. No entanto, ao violar vários níveis de defesa em profundidade, o núcleo foi destruído.

Perrow diz que as operadoras são culpadas por desastres de 60% a 80% das vezes, incluindo a TMI. No entanto, ele acredita que esse número é muito alto. A autópsia é tipicamente feita pelas pessoas que projetaram o sistema, onde a retrospectiva é usada para determinar o que os operadores realmente deveriam ter feito. Ele acredita que a maioria dos problemas são projetados. Como há limites para o quanto você pode eliminar no projeto, deve haver outros meios para mitigar os efeitos quando ocorrem “acidentes normais”.

Nossas lições da TMI são a importância de remover erros latentes, a necessidade de testar os sistemas de recuperação para garantir que eles funcionem e a necessidade de ajudar os operadores a lidar com a complexidade.

2.2 Erro Humano e Ironia de Automação

Por causa da TMI, os pesquisadores começaram a investigar por que os humanos cometem erros. James Reason [1990] faz um levantamento da literatura dessa área e apresenta alguns pontos interessantes. Primeiro, existem dois tipos de erro humano. Deslizes ou lapsos - erros de execução - onde as pessoas não fazem o que pretendiam fazer, e erros - erros de planejamento - onde as pessoas fazem o que pretendiam fazer, mas fizeram a coisa errada. O segundo ponto é que o treinamento pode ser caracterizado como criar regras de produção mental para resolver problemas, e normalmente o que fazemos é passar rapidamente pelas regras de produção até encontrar uma correspondência plausível. Assim, os humanos são combinadores de padrões furiosos. O terceiro ponto da razão é que somos pobres em resolver a partir dos primeiros princípios, e só podemos fazê-lo por muito tempo antes que nossos cérebros se cansem. A tensão cognitiva nos leva a tentar soluções de menor esforço primeiro, normalmente de nossas regras de produção, mesmo quando erradas. Quarto, os humanos detectam erros por conta própria. Cerca de 75% dos erros são detectados imediatamente após serem cometidos. Razão conclui que erros humanos são inevitáveis

Uma segunda observação importante, rotulada de Ironia da Automação, é que a automação não cura o erro humano. O raciocínio é que, uma vez que os designers percebem que os humanos cometem erros, eles geralmente tentam projetar um sistema que reduza a intervenção humana. Muitas vezes, isso apenas muda alguns erros do operador para erros de projeto, que podem ser mais difíceis de detectar e corrigir. Mais importante, a automação geralmente aborda as tarefas fáceis para os humanos, deixando as tarefas complexas e raras que eles não automatizaram com sucesso para o operador. Como os humanos não são bons em pensar a partir dos primeiros princípios, os humanos não são adequados para essas tarefas, especialmente sob estresse. A ironia é que a automação reduz a chance de os operadores obterem experiência prática de controle, o que os impede de criar regras de produção mental e modelos para solução de problemas. Assim, a automação geralmente diminui a visibilidade do sistema, aumenta a complexidade do sistema e limita as oportunidades de interação, o que pode dificultar o uso dos operadores e aumentar a probabilidade de cometer erros ao usá-los. Ironicamente, tentativas de automação podem piorar a situação

Nossas lições da pesquisa de erro humano são que os operadores humanos sempre estarão envolvidos com os sistemas e que os humanos cometerão erros, mesmo quando realmente souberem o que fazer. O desafio é projetar sistemas que sejam sinérgicos com operadores humanos, idealmente dando aos operadores a chance de se familiarizar com os sistemas em um ambiente seguro e corrigir erros quando detectam que os cometeram

2.3 Engenharia Civil e Margem de Segurança

Talvez nenhum campo de engenharia tenha abraçado tanto a segurança quanto a engenharia civil. Petroski [1992] disse que nem sempre foi assim. Com a chegada da ferrovia no século 19, os engenheiros tiveram que aprender a construir pontes que pudessem suportar veículos que pesavam toneladas e andavam rápido

Eles não tiveram sucesso imediato: entre as décadas de 1850 e 1890, cerca de um quarto das pontes ferroviárias de treliça de ferro falharam! Para corrigir essa situação, os engenheiros começaram a estudar as falhas, pois aprendiam com as pontes que caíram do que com as que sobreviveram. Em segundo lugar, eles começaram a adicionar redundância para que algumas peças pudessem falhar, mas as pontes sobreviveriam. No entanto, o grande avanço foi o conceito de margem de segurança; engenheiros melhorariam seus projetos por um fator de 3 a 6 para acomodar o desconhecido. A margem de segurança compensou falhas no material de construção, erros na cura da construção, carga muito alta na ponte ou até mesmo erros no projeto da ponte. Como os humanos projetam, constroem e usam a ponte e como os erros humanos são inevitáveis, a margem de segurança era necessária. Também chamado de margem de ignorância, permite estruturas seguras sem ter que saber tudo sobre o projeto, implementação e uso futuro de uma estrutura. Apesar do uso de supercomputadores e CAD mecânico para projetar pontes em 2002, os engenheiros civis ainda multiplicam a carga calculada por um pequeno número inteiro para garantir.

Um conto de advertência sobre o último princípio vem do RAID. Os primeiros pesquisadores do RAID foram questionados sobre o que aconteceria ao RAID-5 se ele usasse um lote ruim de discos. Sua pesquisa sugeriu que, enquanto houvesse peças de reserva para reconstruir os dados perdidos, o RAID-5 lidaria com lotes ruins e, portanto, garantiram a outros. Um administrador de sistema nos disse recentemente que todos os administradores que ele conhecia perderam dados no RAID-5 uma vez em sua carreira, embora tivessem discos sobressalentes em espera. Como poderia ser? Em retrospecto, o MTTF citado de discos assume temperatura nominal e vibração limitada. Certamente, alguns sistemas RAID foram expostos a temperaturas mais altas e mais vibração do que o previsto e, portanto, tiveram falhas muito mais correlacionadas do que o previsto. Uma segunda falha que ocorreu em muitos sistemas RAID é o operador retirar um disco bom em vez do disco com falha, induzindo assim uma segunda falha. Se isso foi um deslize ou um erro, os dados foram perdidos. Se nosso campo tivesse adotado o princípio da margem de segurança, os documentos do RAID teriam dito que o RAID-5 era suficiente para falhas que poderíamos antecipar, mas recomendaria o RAID-6 (até duas falhas de disco) para acomodar as falhas imprevistas. Nesse caso, pode ter havido significativamente menos interrupções de dados em sistemas RAID.

Nossa lição da engenharia civil é que a justificativa para a margem de segurança é tão aplicável aos servidores quanto às estruturas, e por isso precisamos entender o que uma margem de segurança significa para o nosso campo.

3. Hipóteses do ROC: Repare rapidamente para melhorar a confiabilidade e reduzir o custo de propriedade

Se um problema não tem solução, pode não ser um problema, mas um fato, não a ser resolvido, mas a ser enfrentado ao longo do tempo. – Shimon Pere

A citação de Peres acima é o provérbio orientador da Computação Orientada à Recuperação (ROC). Consideramos erros cometidos por pessoas, software e hardware como fatos, não problemas que devemos resolver, e a recuperação rápida é como lidamos com esses erros inevitáveis. Como a indisponibilidade é aproximadamente MTTR/MTTF, reduzir o tempo de recuperação por um fator de dez é tão valioso quanto aumentar o tempo de falha por um fator de dez. Do ponto de vista da pesquisa, acreditamos que o MTTF recebeu muito mais atenção do que o MTTR e, portanto, pode haver mais oportunidades para melhorar o MTTR. Uma hipótese do ROC é que o desempenho de recuperação é mais frutífero para a comunidade de pesquisa e mais importante para a sociedade do que o desempenho tradicional no século XXI. Dito de forma alternativa, a Lei de Peres será em breve mais importante que a Lei de Moore.

Um benefício colateral da redução do tempo de recuperação é seu impacto no custo de propriedade. A redução do MTTR reduz o dinheiro perdido com o tempo de inatividade. Observe que o custo do tempo de inatividade não é linear. Cinco segundos de inatividade provavelmente não custam nada, cinco horas podem desperdiçar um dia de salário e um dia de receita de uma empresa e cinco semanas levam uma empresa à falência. Assim, a redução do MTTR pode ter benefícios não lineares no custo do tempo de inatividade (consulte a seção 5.5 abaixo). Um segundo benefício é a redução do custo de administração. Uma vez que um terço a metade do tempo do administrador do sistema pode ser gasto na recuperação de falhas ou na preparação para a possibilidade de falha antes de uma atualização, o ROC também pode reduzir o custo pessoal de propriedade. A segunda hipótese do ROC é que as oportunidades de pesquisa e a ênfase do cliente no século 21 estarão no custo total de propriedade e não na medida convencional de preço de compra de hardware e software.

O progresso foi tão rápido no desempenho, em parte porque tínhamos um padrão comum – benchmarks – para medir o sucesso. Para fazer um progresso tão rápido na recuperação, precisamos de incentivos semelhantes. Com qualquer referência, uma das primeiras questões é se é realista. Em vez de adivinhar por que os sistemas falham, precisamos ter os fatos para agir como uma carga de trabalho de falha. A seção 2 acima mostra os dados que coletamos até agora de serviços de Internet e de companhias telefônicas.

Embora estejamos mais interessados nas oportunidades de pesquisa do MTTR, notamos que nosso impulso complementa a pesquisa para melhorar o MTTF, e o saudamos. Dadas as estatísticas na seção 2, não há perigo de hardware, software e operadores se tornarem perfeitos e, assim, tornar o MTTR irrelevante.

4. Seis técnicas ROC

Embora as histórias de desastres e interrupções pareçam assustadoras, as hipóteses ROC e nosso mundo virtual nos permitem tentar coisas impossíveis no mundo físico, o que pode simplificar nossa tarefa. Por exemplo, engenheiros civis podem precisar projetar uma parede para sobreviver a um grande terremoto, mas em um mundo virtual, pode ser tão eficaz deixá-la cair e substituí-la alguns milissegundos depois. Nossa busca por inspiração em outros campos levou a novas técnicas, bem como algumas comumente encontradas. Seis técnicas guia ROC:

Redundância para sobreviver a falhas. Nosso campo há muito usa redundância para obter alta disponibilidade na presença de falhas.
Particionamento para conter falhas e reduzir o custo de atualização. Como esperamos que os serviços usem clusters de computadores independentes conectados por uma rede, deve ser simples usar essa técnica para isolar um subconjunto do cluster em caso de falha ou durante uma atualização. O particionamento também pode ajudar na arquitetura de software para que apenas um subconjunto das unidades precise se recuperar em caso de falha.
Inserção de falhas para testar mecanismos e operadores de recuperação. Não esperamos avanços na recuperação até que seja tão fácil testar a recuperação quanto é hoje para testar a funcionalidade e o desempenho. A inserção da falha é necessário não apenas no laboratório de desenvolvimento, mas no campo para ver o que acontece quando ocorre uma falha em um determinado sistema com sua provável combinação exclusiva de versões de hardware, software e firmware. Assumindo o mecanismo de particionamento acima, devemos ser capazes de inserir falhas em subconjuntos de sistemas ativos sem colocar em risco o serviço. Em caso afirmativo, podemos usar essa combinação para treinar operadores em um sistema ativo, fornecendo falhas para reparo. A inserção de falhas também simplifica a execução de benchmarks de disponibilidade. .Uma técnica relacionada é fornecer entradas de teste aos módulos de um serviço para verificar se eles fornecem o resultado adequado. Tal mecanismo reduz o MTTR reduzindo o tempo de detecção de erros.
Auxílio no diagnóstico da causa do erro. Claramente, o sistema deve ajudar o operador a determinar o que corrigir, e esse auxílio pode reduzir o MTTR. No ambiente de rápida mudança dos serviços de Internet, o desafio é fornecer ajuda que possa acompanhar o ambiente.
Sistemas de armazenamento sem substituição e registro de entradas para permitir que o operador desfaça. Acreditamos que desfazer para os operadores seria um passo muito significativo para fornecer aos operadores um ambiente de tentativa e erro. Para atingir esse objetivo, devemos preservar os dados antigos. Felizmente, alguns sistemas de arquivos comerciais hoje oferecem esses recursos, e a capacidade de disco é a tecnologia de computador que mais cresce.
Mecanismos ortogonais para aumentar a disponibilidade. Fox e Brewer [2000] sugerem que módulos independentes que fornecem apenas uma única função podem auxiliar um serviço. Exemplos são detectores de deadlock de bancos de dados [Gray 1978]; intertravamentos de hardware em Therac [Leveson 1993]; tecnologia de máquina virtual para contenção de falhas e tolerância a falhas [Bres95]; firewalls de segurança e depuradores de disco e memória para reparar falhas antes de serem acessadas pelo aplicativo.

A Figura 3 reúne várias dessas técnicas. Nós rastreamos um serviço durante a operação normal usando alguma métrica de qualidade de serviço, talvez hits por segundo. Como essa taxa pode variar, você captura o comportamento normal usando alguma técnica estatística; na figura, usamos o intervalo de confiança de 99%. Em seguida, inserimos uma falha no hardware ou software. O operador e o sistema devem então detectar a falha, determinar o módulo a ser corrigido e reparar a falha. A principal figura de mérito é o tempo de reparo ou recuperação, incluindo o operador e os erros que ele pode cometer [Brown02].

Figura 3. Exemplo de inserção de falhas. Brown [2000] usa essa abordagem para medir a disponibilidade de sistemas RAID-5 de software de Linux, Solaris e Windows e descobriu que as políticas implícitas levavam a tempos de recuperação que variavam por fatores de 5 a 30.

Apesar dos temores em contrário, você pode acomodar a variabilidade das pessoas e ainda obter resultados válidos com apenas 10 a 20 sujeitos humanos [Neilsen93], ou mesmo com apenas 5 [Neilsen02]. . Embora poucos pesquisadores de sistemas trabalhem com seres humanos, eles são comuns na ciências sociais e na comunidade Human Computer Interface.

5. Estudos de Caso de Técnicas ROC

Dada a definição, hipóteses e técnicas de ROC, quão bem eles funcionam? Esta seção apresenta cinco estudos de caso usando as seis técnicas acima para indicar seus benefícios, destacando especialmente o valor da inserção de falhas na avaliação de novas ideias. Encaixando as raízes desta conferência, vamos do hardware ao software.

5.1 Particionamento de hardware e inserção de falhas: ROC-1

O protótipo de hardware ROC-1 é um cluster de 64 nós composto de nós customizados, chamados bricks, cada um dos quais é uma placa de PC embarcada [Opp02]. A Figura 4 mostra um tijolo. Para eficiência de espaço e energia, os tijolos são empacotados em uma única caixa de disco de meia altura. Ao contrário de outros PCs, cada tijolo possui um processador de diagnóstico (DP) com uma rede de diagnóstico separada, cuja finalidade era monitorar o nó, isolar um nó e inserir erros. A ideia era desligar a energia dos principais chips de forma seletiva, incluindo as interfaces de rede. O DP é um exemplo de mecanismo ortogonal para particionar o cluster e inserir falhas, que são as técnicas ROC #6, #2 e #3.

Figura 4. Um tijolo ROC-1. Cada bloco contém um processador Pentium II móvel de 266 MHz, um disco SCSI de 18 GB, 256 MB de ECC DRAM, quatro interfaces de rede redundantes de 100 Mb/s conectadas a uma Ethernet de todo o sistema e um processador de diagnóstico baseado em MC68376 da Motorola de 18 MHz. Oito blocos cabem em uma bandeja e oito bandejas formam o cluster, além de switches de rede redundantes. Consulte [Opp02] para obter mais detalhes.

O ROC-1 permitiu com sucesso que o DP isolasse subconjuntos de nós; desligando a energia da interface de rede de forma confiável os nós desconectados da rede. Foi menos bem sucedido na inserção de erros controlando o poder. Era preciso muita área da placa e os chips continham muitas funções para que esse controle de energia fosse eficaz.

A lição do ROC-1 é que podemos oferecer particionamento de hardware com componentes padrão, mas a alta quantidade de integração sugere que se a inserção de falha de hardware for necessária, devemos alterar os chips internamente para suportar tais técnicas.

5.2 Inserção de Falha de Software: FIG

A estranheza do isolamento de falhas de hardware no ROC-1 inspirou um experimento de inserção de falhas de software. FIG (Fault Injections in glibc) é uma ferramenta leve e extensível para injetar e registrar erros no limite do aplicativo/sistema. A FIG é executada em sistemas operacionais no estilo UNIX e funciona interpondo uma biblioteca entre o aplicativo e as bibliotecas do sistema glibc que interceptam chamadas do aplicativo para o sistema. Quando uma chamada é interceptada, nossa biblioteca então escolhe, com base nas diretivas de teste de um arquivo de controle, se permite que a chamada seja concluída normalmente ou se retorna um erro que simula uma falha do ambiente operacional. Embora nossa implementação da FIG tenha como alvo as funções implementadas na glibc, ela pode ser facilmente adaptada para instrumentar qualquer biblioteca compartilhada.

Para testar a eficácia da FIG, começamos com três aplicativos maduros: o editor de texto Emacs (usando X e sem usar X), a biblioteca de banco de dados de arquivos simples de código aberto Berkeley DB (com e sem transações) e o servidor http de código aberto Apache. Assumimos que, se a inserção de falhas ajudasse a avaliar a confiabilidade de softwares maduros, certamente seria útil para softwares recém-desenvolvidos.

Inserimos erros em uma dúzia de chamadas de sistema e a Tabela 2 mostra os resultados para read(), write(), select() e malloc(). Tentamos o Emacs com e sem o sistema de widowing X, e ele se saiu muito melhor sem ele: EIO e ENOMEM causaram travamentos com o X, e um comportamento mais aceitável resultou sem ele. Como esperado, o Berkeley DB no modo não transacional não tratou os erros normalmente, pois erros de gravação podem corromper o banco de dados. No modo transacional, ele detectou e se recuperou de todos os erros de memória, exceto corretamente. O Apache foi o “best of show”, pois foi o mais robusto dos aplicativos testados.

Uma lição da FIG é que mesmo programas maduros e confiáveis têm interfaces mal documentadas e mecanismos de recuperação de erros ruins. Concluímos que o desenvolvimento de aplicativos pode se beneficiar de uma estratégia de teste abrangente que inclua mecanismos para introduzir erros do ambiente do sistema, mostrando o valor desse princípio ROC (#3). A FIG fornece um método direto para a introdução de erros. Não só a FIG pode ser usada no desenvolvimento para depurar o código de recuperação, mas em conjunto com o particionamento de hardware, ela pode ser usada na produção para ajudar a expor erros latentes no sistema.

Tabela 2. Reação de aplicativos a falhas inseridas em quatro chamadas de sistema. EINTER = Exceção/Interrupção, EIO = erro de E/S, ENOSPC = sem espaço em disco, ENOMEM = sem espaço na memória principal. Veja [BST02] para mais detalhes.

Mesmo com esse número limitado de exemplos, a FIG também nos permite ver a programação de aplicativos bem-sucedida e malsucedida. Três exemplos de práticas bem-sucedidas são a pré-alocação de recursos: solicitar todos os recursos necessários na inicialização para que não ocorram falhas no meio do processamento; degradação graciosa: oferecendo serviço parcial em face de falhas para melhorar o tempo de inatividade; e repetição seletiva: esperar e repetir uma chamada de sistema com falha um número limitado de vezes, na esperança de que os recursos fiquem disponíveis. A FIG ajuda a avaliar um módulo suspeito, enquanto o próximo estudo de caso ajuda o operador a encontrar o culpado.

5.3 Diagnóstico Automático: Pontual

Qual é o desafio? Um serviço de Internet típico tem muitos componentes divididos entre várias camadas, bem como vários subcomponentes (replicados) em cada camada. À medida que os clientes se conectam a esses serviços, suas solicitações são roteadas dinamicamente pelo sistema. O grande tamanho desses sistemas resulta em mais locais para ocorrência de falhas. O aumento no comportamento dinâmico significa que há mais caminhos que uma solicitação pode seguir pelo sistema e, portanto, resulta em mais falhas potenciais devido a falhas de “interação” entre os componentes. Além disso, mudanças rápidas no hardware e software dos serviços dificultam o diagnóstico automatizado.

As técnicas de diagnóstico de falhas tradicionalmente usam modelos de dependência, que são dependências de componentes geradas estaticamente para determinar quais componentes são responsáveis pelos sintomas de um determinado problema. Os modelos de dependência são difíceis de gerar e difíceis de manter consistentes com um sistema em evolução. Além disso, eles refletem as dependências dos componentes lógicos, mas não diferenciam os componentes replicados. Por exemplo, duas solicitações idênticas podem usar instâncias diferentes dos mesmos componentes replicados. Portanto, os modelos de dependência podem identificar qual componente está com falha, mas não qual instância do componente. Portanto, eles são uma combinação ruim para os serviços de Internet de hoje.

Em vez disso, usamos a metodologia de análise dinâmica que automatiza a determinação de problemas nesses ambientes sem análise de dependência. Primeiro, rastreamos dinamicamente solicitações de clientes reais por meio de um sistema. Para cada solicitação, registramos seu sucesso ou falha acreditado e o conjunto de componentes usados para atendê-la. Em seguida, realizamos agrupamento de dados padrão e técnicas estatísticas para correlacionar as falhas de solicitações aos componentes com maior probabilidade de tê-las causado.

Traçando solicitações reais através do sistema, vamos usar determinar problemas em sistemas dinâmicos onde a modelagem de dependência não é possível. Esse rastreamento também nos permite distinguir entre várias instâncias do que seria um único componente lógico em um modelo de dependência. Ao realizar o agrupamento de dados para analisar os sucessos e falhas das requisições, encontramos as combinações de componentes que estão mais correlacionadas com as falhas das requisições, sob a crença de que esses componentes estão causando as falhas. Ao analisar os componentes usados nas solicitações com falha, mas não usados nas solicitações bem-sucedidas, fornecemos alta precisão com número relativamente baixo de falsos positivos. Essa análise detecta componentes defeituosos individuais, bem como falhas que ocorrem devido a interações entre vários componentes. Além disso, essa análise tende a ser robusta diante de múltiplas falhas independentes e falhas espúrias. Chamamos esse sistema de Pinpoint; veja [Chen02] para mais detalhes.

Implementamos um protótipo do Pinpoint sobre o middleware Java2 Enterprise Edition (J2EE). Nosso protótipo não requer nenhuma modificação nos aplicativos J2EE. O único conhecimento de aplicação que nosso protótipo requer são verificações específicas de aplicação para permitir a detecção de falhas externas e, mesmo neste caso, nenhum componente de aplicação precisa ser modificado. Por causa disso, o Pinpoint pode ser um auxílio na determinação de problemas para quase qualquer aplicativo J2EE. Para avaliar o impacto no desempenho, comparamos um aplicativo hospedado em um servidor J2EE não modificado e em nossa versão com o registro ativado e descobrimos que a sobrecarga do Pinpoint era de apenas 8,4%.

A medida de sucesso na determinação do problema não é apenas a fração de falhas identificadas corretamente, mas também a taxa de falsos positivos. Dependendo das circunstâncias, você pode estar mais preocupado com altas taxas de acerto ou baixas taxas de falsos positivos. Das estatísticas vem uma técnica, coincidentemente abreviada ROC (receiver operating characteristic), para traçar a relação entre a taxa de acerto e a taxa de falso-positivo. Um “botão” de sensibilidade é alterado, o que normalmente aumenta a taxa de acertos e os falsos positivos. Bons resultados são para cima (alta taxa de acertos) e para a esquerda (baixa taxa de falsos positivos). Por exemplo, se houvesse 10 módulos reais defeituosos, uma taxa de acerto de 0,9 com uma taxa de falsos positivos de 0,2 significaria que o sistema identificou corretamente 9 dos 10 módulos reais e forneceu 2 falsos.

Figura 5. Uma análise ROC da taxa de acertos vs. taxa de falsos positivos. Para validar nossa abordagem, executamos o aplicativo de demonstração J2EE Pet Store e injetamos sistematicamente falhas no sistema em uma série de execuções. Executamos 55 testes que incluíram falhas de componente único e falhas desencadeadas por componentes de interações. Este gráfico mostra falhas de componente único. É importante notar que nosso sistema de injeção de falhas é mantido separado do nosso sistema de detecção de falhas. O método de agrupamento usado para a análise Pinpoint foi o método de grupo de pares não ponderado usando médias aritméticas com o coeficiente de similaridade de Jaccard. [Jain 1988] O “botão” de sensibilidade define a distância (entre elementos) na qual paramos de mesclar elementos/grupos. A análise de dependência examina os componentes usados em solicitações com falha. O botão de sensibilidade é a lista de componentes que ocorreram em pelo menos X% das solicitações com falha, onde X é a configuração de sensibilidade. Quando 0%, é o conjunto de componentes que são usados em todas as solicitações com falha; quando 100%, é o conjunto usado em qualquer uma das solicitações com falha. As duas linhas são a interpolação da curva Bezier dos pontos de dados. Para obter mais detalhes, consulte [Chen02].

A Figura 5 compara o Pinpoint a uma análise de dependência mais tradicional usando ROC. Mesmo em uma configuração de baixa sensibilidade, o Pinpoint inicia com uma taxa de falsos positivos de apenas 0,1 combinada com uma taxa de acerto acima de 0,6. Aumentar a sensibilidade empurra a taxa de falsos positivos de 0,5 com uma taxa de acerto para 0,9. Em contraste, a abordagem de dependência simples começa com uma taxa de falsos positivos muito alta: 0,9. A configuração de sensibilidade pode melhorar a taxa de acerto de 0,7 para 0,9, mas a taxa de falsos positivos começa em 0,9 e permanece lá.

Ficamos satisfeitos com a precisão e a sobrecarga do Pinpoint, especialmente devido à sua capacidade de corresponder à natureza dinâmica e replicada dos serviços de Internet. Uma limitação do Pinpoint é que ele não consegue distinguir entre conjuntos de componentes fortemente acoplados que sempre são usados juntos. Estamos analisando a inserção de entradas de teste para isolar esses módulos. Outra limitação do Pinpoint, bem como das abordagens de determinação de erros existentes, é que ele não funciona com falhas que corrompem o estado e afetam as solicitações subsequentes. A não independência das solicitações dificulta a detecção das falhas reais porque as solicitações subsequentes podem falhar ao usar um conjunto diferente de componentes.

Este estudo de caso mostrou um exemplo de auxílio ao diagnóstico (técnica ROC #4) usando a inserção de falhas (#3) para ajudar a avaliá-lo. O Pinpoint pode reduzir o tempo de recuperação reduzindo o tempo para o operador encontrar a falha, mas o próximo estudo de caso reduz o tempo de recuperação de um sistema após a identificação do módulo.

5.4 Reinicialização Recursiva e Particionamento de Grão Fino: Mercury

Em Mercury, uma estação terrestre de satélite, empregamos reinicializações parciais de grão fino para reduzir o tempo médio de recuperação do software de controle em quase um fator de seis. Além de ser uma melhoria quantitativa significativa, também constituiu uma melhoria qualitativa que levou a uma disponibilidade próxima de 100% da estação terrestre durante o período crítico em que o satélite passa por cima.

A capacidade de reinicialização recursiva [Candea01a] é uma abordagem para recuperação do sistema baseada na observação de que, em infraestruturas críticas, a maioria dos bugs faz com que o software falhe, trava, gire, livelock, vaze memória, corrompe o heap e assim por diante, deixando uma reinicialização ou reinicialização como a única maneira de alta confiança de colocar o sistema de volta em operação [Brewer01, Gray78]. As reinicializações são uma solução eficaz e eficiente porque são fáceis de entender e empregar, fornecem uma maneira de alta confiança para recuperar recursos obsoletos ou vazados e retornam inequivocamente o software ao seu estado inicial - geralmente o melhor estado testado e compreendido do sistema. Infelizmente, a maioria dos sistemas não tolera reinicializações não anunciadas, resultando em tempos de inatividade desnecessariamente longos associados à possível perda de dados. Um sistema recursivamente reiniciável (RR), no entanto, tolera normalmente reinicializações sucessivas em vários níveis. O particionamento de grão fino permite reinicializações parciais limitadas que recuperam um sistema com falha mais rapidamente do que uma reinicialização completa. O RR também permite uma forte contenção de falhas, diagnóstico e benchmarking [Candea01b].

Aplicamos as ideias do RR a Mercury, uma estação terrestre para satélites de baixa órbita terrestre, que atualmente controla a comunicação com dois satélites em órbita. O Mercury é construído a partir de antenas e rádios COTS, acionados por PCs baseados em x86 executando Linux com a maior parte do software escrito em Java. A Mercury rompe com a tradição da comunidade de satélites ao enfatizar o baixo custo de produção em detrimento da missão crítica.

Figura 6. Aplicando a Reinicialização Recursiva a uma estação terrestre de satélite. As instâncias do Mercury antes e depois da aplicação do RR são descritas pelas duas árvores de reinicialização. O Mercury consiste em vários componentes: um backbone de comunicação para mensagens XML (msgbone), um tradutor de comandos XML (fedr), uma porta serial para mapeador de soquete TCP (pbcom), um estimador de posição e azimute (ise), um rastreador de satélite ( istr) e um sintonizador de rádio (istu). A primeira linha da tabela indica os MTTFs observados desses componentes com base em 2 anos de operação. As duas últimas linhas mostram o efeito das transformações no tempo de recuperação do sistema, em função do componente que falha.

A Figura 6 mostra que um sistema reiniciável recursivamente, do qual o Mercury é um exemplo, pode ser descrito por uma árvore de reinicialização - uma hierarquia de componentes reiniciáveis em que os nós são altamente isolados de falhas. Uma reinicialização em qualquer nó resulta na reinicialização de toda a subárvore enraizada naquele nó. Uma árvore de reinicialização não captura dependências funcionais entre componentes, mas sim as dependências de reinicialização. As subárvores representam grupos de reinicialização, que agrupam componentes com requisitos de reinicialização comuns. Com base nas informações de quais componentes falharam (por exemplo, usando os métodos Pinpoint descritos acima), um oráculo determina qual nó na árvore deve ser reiniciado. O objetivo de um oráculo perfeito é sempre escolher um conjunto mínimo de subsistemas que precisam ser reiniciados, a fim de minimizar o tempo de recuperação. Se uma reinicialização em particular não curar a falha, o oráculo pode optar por subir na árvore e reiniciar em um nível mais alto. Reiniciar grupos que estão mais acima na árvore de reinicialização leva a uma recuperação de confiança mais longa, porém mais alta.

Para minimizar o tempo de recuperação em Mercúrio, [Candea02]. descreve uma série de transformações que aplicamos. A Figura 6 resume o resultado dessas transformações. O resultado mais convincente é uma redução de seis vezes no tempo de recuperação para falhas que ocorrem no fedr. Como esse componente falhou com muita frequência devido a travamentos da JVM, a diminuição quantitativa no tempo de recuperação levou a um aumento qualitativo na disponibilidade. Usando a frequência de falhas na Figura 6, o tempo médio ponderado de recuperação cai de 28,9 segundos para 5,6 segundos.

Já é um fato aceito que nem todo tempo de inatividade é igual. O tempo de inatividade sob uma carga de trabalho pesada ou crítica é mais caro do que o tempo de inatividade sob uma carga de trabalho leve ou não crítica, e o tempo de inatividade não planejado geralmente é mais caro do que o tempo de inatividade planejado [Brewer01]. Relevante para o espaço de serviço, o Mercury constitui um exemplo interessante no espaço de missão crítica: o tempo de inatividade durante as passagens de satélite é muito caro porque podemos perder dados científicos e telemetria. Pior ainda, se a falha envolver o subsistema de rastreamento e o tempo de recuperação for muito longo, podemos perder todo o passe; a antena e a espaçonave ficarão suficientemente desalinhadas para que a antena não possa alcançá-la a tempo quando o subsistema de rastreamento voltar a ficar online. Um MTTF grande não garante um passe livre de falhas, mas um MTTR curto pode ajudar a garantir que não perderemos o passe inteiro por causa de uma falha. Como na Seção 3, aqui está outro exemplo em que o custo do tempo de inatividade não é linear em sua duração. Essa mudança quantitativa no tempo de recuperação, levando a uma mudança qualitativa no comportamento do sistema, foi observada em várias infraestruturas de grande escala. Por exemplo, em 11 de setembro de 2001, o longo tempo de recuperação do site CNN.com impediu que todo o site se recuperasse sob carga aumentada [LeFebvre01].

A aplicação da capacidade de reinicialização recursiva a um sistema de missão crítica nos permitiu reduzir o tempo de recuperação de vários tipos de falhas e atingir quase 100% de disponibilidade em relação às passagens de satélite. A estação terrestre Mercury é um exemplo de um sistema ROC de ponta a ponta que incorpora ganchos de partição de grão fino para inserção de falhas, auxílio baseado em registro para diagnóstico de erro e mecanismos ortogonais fortes, ou técnicas ROC #2, #3, #4 , e #6. A Mercury mostrou como reduzir o tempo de recuperação de falhas de software ou hardware, enquanto a próxima técnica também ajuda na recuperação de falhas do operador.

5.5 Recuperação via Undo: Design de um sistema de e-mail que pode ser desfeito

Nosso último estudo de caso é uma camada Undo projetada para fornecer um ambiente mais tolerante para operadores de sistemas humanos; ele ilustra as técnicas ROC de usar sistemas de armazenamento sem sobrescrever com registro de entrada (#5) e mecanismos ortogonais (#6). Temos dois objetivos aqui. A primeira é fornecer um mecanismo que permita que os operadores se recuperem de seus erros inevitáveis; lembre-se da Seção 2 que os erros do operador são uma das principais causas de falhas de serviço hoje. O segundo objetivo é fornecer aos operadores uma ferramenta que permita reparar retroativamente erros latentes que não foram detectados até tarde demais. Aqui aproveitamos o fato de que os computadores operam em um mundo virtual no qual os efeitos de erros latentes podem ser revertidos, ao contrário de sistemas físicos como o TMI.

Escolhemos o email como o aplicativo de destino para nossa primeira implementação de uma camada ROC Undo. O e-mail tornou-se um serviço essencial para as empresas de hoje, muitas vezes atuando como o “sistema nervoso” de comunicações para empresas e indivíduos, e é um dos serviços mais comuns oferecidos pelos fornecedores de serviços de rede. Os sistemas de e-mail também oferecem muitas oportunidades para erros do operador e reparos retroativos. Exemplos de erros do operador que podem ser resolvidos por nossa camada de desfazer incluem: filtros mal configurados (spam, antivírus, procmail e assim por diante) que excluem inadvertidamente e-mails de usuários, exclusão acidental de caixas de correio de usuários, corrupção de e-mails ao redistribuir caixas de correio de usuários para balancear a carga e instalação de atualizações de software com bugs ou quebradas que executam mensagens incorretas ou corrompidas. O reparo retroativo é útil em um sistema de e-mail quando vírus ou spammers atacam: com um sistema de desfazer, o operador pode “desfazer” o sistema de volta ao ponto anterior ao ataque de vírus ou spam, instalar retroativamente um filtro para bloquear o ataque e depois “ refazer” o sistema de volta ao tempo presente. Além disso, a abstração de desfazer pode se propagar para o usuário, permitindo que o usuário se recupere de erros inadvertidos, como a exclusão acidental de mensagens ou pastas sem envolver o administrador do sistema.

Para dar suporte à recuperação de erros do operador e reparo retroativo, nosso modelo de desfazer ROC oferece suporte a um processo de desfazer de 3 etapas que denominamos “os três R s”: Rebobinar, Reparar e Repetir. Na etapa de retrocesso, todo o estado do sistema (incluindo o conteúdo da caixa de correio, bem como o estado físico do sistema operacional e do aplicativo) é revertido para seu conteúdo em um momento anterior (antes da ocorrência do erro). Na etapa de reparo, o operador pode fazer qualquer alteração no sistema que desejar. As alterações podem incluir corrigir um erro latente, instalar um filtro ou patch preventivo ou simplesmente tentar novamente uma operação que não teve êxito na primeira vez (como uma atualização de software do servidor de e-mail). Por fim, na etapa de replay, o sistema de desfazer reexecuta todas as interações do usuário com o sistema, reprocessando-as com as alterações feitas durante a etapa de reparo. É claro que existem muitos desafios na implementação do modelo 3R, principalmente na reprodução de interações que já podem ter se tornado visíveis externamente antes do início do ciclo de desfazer. Mais detalhes descrevendo nossas abordagens estão em [Brown02].

Estamos construindo um protótipo de implementação de nossa camada de desfazer direcionada por e-mail. Nosso protótipo foi projetado como uma camada de proxy que envolve um servidor de e-mail existente e não modificado baseado em IMAP e SMTP. Optamos por construir a camada de desfazer como um proxy para permitir a recuperação de erros do operador durante eventos importantes, como atualizações de software do servidor de correio. A Figura 7 ilustra o funcionamento do proxy.

Além do proxy, o outro componente principal do nosso protótipo é uma camada de armazenamento não sobrescrita que fica abaixo do servidor de e-mail. Essa camada permite a fase de retrocesso de desfazer, fornecendo acesso a versões históricas do estado rígido do sistema. A camada de viagem no tempo pode ser implementada usando instantâneos do sistema de arquivos (como os fornecidos pelo sistema de arquivos WAFL da Network Appliance [Hitz95]), embora estejamos investigando o uso de um sistema de versão mais flexível, como o sistema de arquivos Elephant [Santry99].

Uma análise dos logs de tráfego de nosso servidor de correio departamental para 1.200 usuários indica que a sobrecarga de armazenamento de manter o log de desfazer é de cerca de 250 MB/dia usando nosso protótipo não otimizado. Um único disco EIDE de 120 GB, que custava apenas US$ 180 em 2002, armazena mais de um ano de dados de log; não muito para obter os 3Rs.

Figura 7. Arquitetura da camada Undo para Email. Durante a operação normal, o proxy bisbilhota o tráfego IMAP e SMTP destinado ao servidor de correio e registra a entrega de correio e as interações do usuário. O proxy também monitora os acessos a mensagens e pastas e usa essas informações para rastrear o estado que se tornou visível externamente; isso permite que o sistema emita ações de compensação apropriadas quando o ciclo de reparo/repetição invalida o estado anteriormente externalizado. Mediante uma solicitação de desfazer, a camada de armazenamento que não substitui é revertida para o ponto de desfazer, o operador executa todos os reparos necessários e, em seguida, o proxy reproduz as interações do usuário registradas que foram perdidas durante a reversão. O proxy continua a registrar e-mails recebidos durante o ciclo de desfazer, embora os usuários recebam apenas acesso somente leitura até que a reprodução seja concluída

6. Trabalho Relacionado

Não somos os primeiros a pensar em recuperação; muitos sistemas comerciais e de pesquisa abordaram partes da agenda ROC que definimos neste artigo. A comunidade de armazenamento provavelmente está mais perto de abraçar o ideal ROC do que qualquer outra. A maioria dos fornecedores de armazenamento comercial oferece produtos explicitamente projetados para melhorar o desempenho da recuperação; um bom exemplo é o sistema TimeFinder da EMC [EMC02]. O TimeFinder particiona e replica automaticamente o armazenamento; A EMC sugere que as partições alternativas sejam usadas para testes on-line isolados do tipo ROC e para rápida recuperação pós-crash de grandes sistemas de serviço, como o Microsoft Exchange. Na comunidade de pesquisa, técnicas de aprimoramento de recuperação surgiram por acaso do trabalho originalmente focado em desempenho, como no desenvolvimento de sistemas de arquivos baseados em registro em diário, registro e atualização suave [Rosenblum92] [Seltzer93] [Hitz95].

O trabalho orientado à recuperação na comunidade do sistema operacional é mais raro, mas ainda está presente. Grande parte dele se concentra na capacidade de reiniciar rapidamente após falhas. Um exemplo inicial é a “Caixa de Recuperação” da Sprite, na qual o sistema operacional usa uma área protegida de memória não volátil para armazenar o estado crucial necessário para uma recuperação rápida [Baker92]. Essa ideia básica de segregar e proteger o estado duro crucial para simplificar a recuperação reaparece com frequência, por exemplo, nos derivados do sistema do Rio [Chen96][Lowell97][Lowell98], e em trabalhos recentes sobre a segregação de estado suave/estado duro em Arquiteturas de serviços de Internet [Fox97] [Gribble00]. A maioria desses sistemas ainda usa o aumento do desempenho como motivação para suas técnicas; os benefícios de recuperação são a cereja do bolo.

A comunidade de banco de dados há muito presta atenção à recuperação, usando técnicas como registro antecipado de gravação [Mohan92] e replicação [Gray96] para proteger a integridade dos dados em caso de falhas. O desempenho de recuperação também tem sido um tópico de pesquisa começando com o sistema POSTGRES, onde eles redesenharam o formato de log do banco de dados para permitir uma recuperação quase instantânea [Stonebraker87]. Um exemplo recente de recuperação é o Oracle 9i, que inclui um novo mecanismo Fast Start para recuperação rápida pós-crash [Lahiri01] e uma versão limitada de um sistema de desfazer que permite aos usuários visualizar instantâneos de seus dados de tempos anteriores [Oracle01]. Em geral, no entanto, o desempenho da transação ofuscou em muito o desempenho da recuperação, provavelmente devido à influência dos benchmarks TPC orientados para o desempenho.

Finalmente, a comunidade tradicional de tolerância a falhas ocasionalmente dedicou atenção à recuperação. O melhor exemplo disso é o trabalho de rejuvenescimento de software, que reinicia periodicamente os módulos do sistema para eliminar erros latentes [Huang95] [Garg97] [Bobbio98]. Outra ilustração está no trabalho de autoteste integrado em sistemas embarcados, nos quais os componentes são projetados para verificar proativamente possíveis erros latentes e imediatamente falhar e reiniciar quando algum for encontrado [Steininger99]. Em geral, no entanto, a comunidade de tolerância a falhas não acredita na lei de Peres e, portanto, se concentra no MTTF sob a suposição de que as falhas geralmente são problemas que podem ser conhecidos com antecedência e devem ser evitados.

Nossa abordagem ROC se diferencia deste trabalho anterior de duas maneiras fundamentais. Primeiro, o ROC trata a recuperação de forma holística: um sistema ROC deve ser capaz de se recuperar de qualquer falha em qualquer nível do sistema, e a recuperação deve abranger todas as camadas. Compare isso com, digamos, recuperação de banco de dados ou armazenamento, em que a recuperação se preocupa apenas com os dados no banco de dados/armazenamento e não com todo o comportamento do serviço construído em cima. Em segundo lugar, o ROC cobre um espaço de falha muito mais amplo do que essas abordagens existentes. Em particular, o ROC aborda falhas induzidas por humanos, que são quase totalmente ignoradas no trabalho de sistemas existentes. O ROC também não faz suposições sobre quais falhas podem ocorrer. O trabalho tradicional de tolerância a falhas normalmente limita sua cobertura a um conjunto de falhas previstas por um modelo; no ROC, assumimos que tudo pode acontecer e fornecemos mecanismos para lidar com falhas imprevistas.

Cada técnica ROC neste artigo se baseia em um histórico de trabalho anterior. Embora as limitações de espaço nos impeçam de entrar em detalhes completos, fornecemos algumas dicas aqui para o leitor interessado.

Medições de disponibilidade: O trabalho seminal na coleta de dados de disponibilidade é o estudo de Gray sobre falhas de sistemas de computador Tandem [Gray86]. Trabalhos mais recentes incluem estudos de disponibilidade de sistemas VAX e Windows 2000 [Murphy95] [Murphy00] de Murphy.
Inserção de falhas: A inserção de falhas tem uma longa história na comunidade de tolerância a falhas e abrange uma gama de técnicas de irradiação de íons pesados [Carreira99] para simulação de software de bugs de hardware [Segal88] [Arlat92] e erros de programação [Chandra98] [Kao93] . A maioria dos trabalhos existentes usa a inserção de falhas como uma técnica offline usada durante o desenvolvimento do sistema, embora existam alguns sistemas que foram construídos com a capacidade de injeção de falhas online (principalmente os mainframes IBM 3090 e ES/9000 [Merenda92]).
Diagnóstico de problemas: Existem várias abordagens padrão para o diagnóstico de problemas. Uma é usar modelos e gráficos de dependência para realizar o diagnóstico [Choi99] [Gruschke98] [Katker97] [Yemini96]. Quando os modelos não estão disponíveis, eles podem ser descobertos [Kar00] [Brown01] [Miller95], ou técnicas alternativas podem ser usadas, como a combinação específica do sistema Banga de monitoramento, aumento de protocolo e correlação entre camadas [Banga00] . Nosso exemplo do Pinpoint demonstra outra abordagem ao rastrear solicitações por meio do sistema, como é feito em monitores de utilização de recursos distribuídos [Reumann00]
Undo: Nosso modelo de “undo para operadores”, baseado nos três Rs de rebobinar, reparar e reproduzir, parece ser único em sua capacidade de suportar mudanças arbitrárias durante o estágio de reparo. No entanto, existem muitos sistemas semelhantes que oferecem um subconjunto dos três R s, incluindo sistemas como o EMC TimeFinder [EMC02], uma série de sistemas de ponto de verificação e instantâneos [Elnozahy96] [Borg89] e recuperação de log de banco de dados tradicional [Mohan92]. Além disso, nossa implementação de desfazer depende muito do trabalho existente em sistemas de armazenamento sem substituição.
Benchmarking people: Embora a inclusão do comportamento humano em nossos benchmarks e sistemas ROC possa ser novidade na comunidade de sistemas, é algo que vem sendo feito há anos na comunidade HCI. (Landauer [1997] fornece uma excelente pesquisa sobre métodos e técnicas de HCI.) Nossas intenções são um pouco diferentes, no entanto: HCI está principalmente preocupado com a interface, enquanto queremos abordar o comportamento do sistema quando o humano é incluído, independentemente da interface . Nesse sentido, nosso trabalho é mais semelhante ao trabalho na comunidade de segurança sobre a eficácia de UIs relacionadas à segurança, como o estudo de Whitten e Tygar sobre PGP [Whitten99].

7. Discussão e Orientações Futuras

Se é importante, como você pode dizer que é impossível se você não tentar? Jean Monnet, fundador da União Europeia

Apresentamos estatísticas sobre por que os serviços falham, descobrindo que o erro do operador é uma das principais causas de interrupções e, portanto, parte do custo de propriedade. Seguindo a Lei de Peres, a ROC assume que falhas de hardware, software e operadores são inevitáveis, e a recuperação rápida melhora a disponibilidade e o custo de propriedade. Argumentamos que a coleta de dados de falhas, benchmarks de disponibilidade envolvendo pessoas e margem de segurança serão necessários para o sucesso. Apresentamos seis técnicas ROC, algumas das quais foram inspiradas em outros campos. Eles são redundância, particionamento, inserção de falhas, auxílio ao diagnóstico, armazenamento sem sobregravação e mecanismos ortogonais. Listamos cinco estudos de caso que utilizam essas técnicas: um cluster com particionamento de hardware e inserção de falhas, uma biblioteca de software que insere falhas, middleware que diagnostica falhas, software particionado que recupera mais rapidamente e projeto de um serviço de e-mail com operador undo

O hábito é um poderoso atrativo para os pesquisadores continuarem a abraçar o desempenho, pois certamente temos tido sucesso e sabemos fazer mais. Infelizmente, ele não passa em um teste de senso comum. Se não gastaríamos nosso próprio dinheiro para comprar um computador mais rápido, já que nosso antigo ainda é rápido o suficiente, por que quase todos nós estamos pesquisando como tornar os sistemas mais rápidos?

O ROC parece difícil agora porque não temos certeza se sabemos como ou se podemos fazê-lo. Mas, como a citação acima sugere, se você concorda que a confiabilidade e a manutenção são importantes, como dizer que é impossível se você não tentar?

Nesta fase inicial, o horizonte está repleto de importantes desafios e oportunidades:

Precisamos de uma teoria de construção de sites confiáveis e sustentáveis para serviços em rede.
Precisamos de uma teoria de um bom design para os operadores, bem como um bom design para os usuários finais. Usando uma analogia de companhia aérea, é como se tivéssemos boas diretrizes para passageiros, mas não para pilotos.
Precisamos de uma definição mais sutil de falha do que para cima ou para baixo. Talvez possamos encontrar o equivalente em tecnologia da informação das chamadas bloqueadas (Figura 2) coletadas pelas companhias telefônicas?
Precisamos quantificar economicamente o custo de tempo de inatividade e propriedade, pois se não houver maneiras fáceis de medi-los para uma organização, quem comprará novos sistemas que alegam melhorá-los?
Precisamos continuar a busca por dados reais de falhas e desenvolver benchmarks úteis de disponibilidade e manutenibilidade. Essa busca nos permite medir o progresso, diminuir as barreiras à publicação por pesquisadores e humilhar os produtores de produtos de computador não confiáveis
O design do nosso protótipo inicial de e-mail é intencionalmente simplista e serve principalmente como um teste para examinar as políticas que regem as ações externalizadas. Em versões futuras, pretendemos estender o protótipo fornecendo desfazer por usuário (para permitir que os usuários corrijam seus próprios erros), fornecendo acesso de leitura e gravação durante o ciclo de desfazer, sintetizando estados consistentes das informações no log e adicionando ganchos ao servidor de correio para reduzir a complexidade do proxy e melhorar ainda mais o tempo de recuperação do sistema. Nossa intenção é que este protótipo eventualmente alavanque todas as seis técnicas ROC.
Dada a dificuldade de inserção de falhas de hardware, pode valer a pena investigar as máquinas virtuais como um dispositivo de inserção de falhas. Confiar em uma VM é mais parecido com confiar em um processador do que confiar em um sistema operacional completo [CN01]. Eles também podem ajudar no particionamento e até mesmo no tempo de recuperação, pois pode ser plausível ter peças sobressalentes em espera de máquinas virtuais para assumir o controle de uma falha. Finalmente, um sistema mal comportado pode ocupar tantos recursos que pode ser difícil para o operador fazer login e matar os processos problemáticos, mas a VM oferece uma saída.

Reconhecimentos

NSF ITR, NSF Career Award, + suporte da empresa: Acies Network, Microsoft.

Referências

[Arlat92] J. Arlat, A. Costes, et al. Injeção de Falhas e Avaliação da Confiabilidade de Sistemas Tolerantes a Falhas. Relatório de Pesquisa LAAS-CNRS 91260, janeiro de 1992.
[Baker92] M. Baker e M. Sullivan. A caixa de recuperação: usando a recuperação rápida para fornecer alta disponibilidade no ambiente unix. Proc. da Summer USENIX Conf., junho de 1992. [Banga00] G. Banga. Autodiagnóstico de Problemas de Campo em um Sistema Operacional de Aparelho. Proc. da 2000 USENIX Annual Technical Conf., San Diego, CA, junho de 2000. [Bobbio98] A. Bobbio e M. Sereno. Modelos de rejuvenescimento de software de granulação fina. Proc. IEEE Int’l.Computer Performance and Dependability Symp., Set. 1998, pp. 4—12.
[Borg89] A. Borg, W. Blau, W. Graetsch et al. Tolerância a falhas no UNIX. ACM Transactions on Computer Systems, 7(1):1-24, fevereiro de 1989.
[Bres95] T.C. Bressoud e F. B. Schneider. Tolerância a falhas baseada em hipervisor. Em Proc. Décima Quinta ACM Symp. em Oper. Sistema Princípios (SOSP-15), Copper Mtn., CO, dezembro de 1995.
[Cervejeiro 01] Cervejeiro, E.A. Lições de serviços de grande escala. IEEE Internet Computing, vol.5, (no.4), IEEE, julho-agosto. 2001. p.46-55.
[BST02] Broadwell, P, Naveen Sastry Jonathan Traupman. Injeção de falhas em glibc (FIG), www.cs.berkeley.edu/~nks/fig/paper/fig.html.
[Brown00] A. Brown e D.A. Patterson. Em direção a benchmarks de disponibilidade: um estudo de caso de sistemas RAID de software. Proc 2000 USENIX Annual Technical Conf., San Diego, CA, junho de 2000.
[Brown01] A. Brown, G. Kar e A. Keller. Uma Abordagem Ativa para Caracterizar Dependências Dinâmicas para Determinação de Problemas em um Ambiente Distribuído. Proc 7th IFIP/IEEE Int’l.Symp.on Integrated Network Management (IM VII), Seattle, WA, maio de 2001.
[Brown02] A. Brown e D.A. Patterson, Design de um sistema de e-mail com Undo. Em preparação. [Candea01a] Candea, G.; Fox, A. Reinicialização recursiva: transformando a marreta de reinicialização em um bisturi. Proc. 8º Workshop sobre Hot Topics em Sistemas Operacionais, 2001. p.125-30.
[Candea01b] Candea, G.; Fox, A, Projetando para alta disponibilidade e mensurabilidade, 1º Workshop sobre Avaliação e Arquitetura de Confiabilidade do Sistema G Teborg, Suécia, 1º de julho de 2001.
[Candea02] Candea, G.; Fox, A. et ai. Reinicialização recursiva para Mercúrio, em preparação..
[Carreira99] J. Carreira, D. Costa e J. Silva. A injeção de falhas verifica a confiabilidade do sistema do computador. IEEE Spectrum 36(8):50-55, agosto de 1999.
[Chandra98] S. Chandra e P. M. Chen. Como o Fail Stop são programas defeituosos? Proc. de 1998 Symp.on Fault-Tolerant Computing (FTCS), junho de 1998.
[Chen96] P. M. Chen, W. T. Ng, S. Chandra, et al. O cache de arquivos do Rio: sobrevivendo a falhas do sistema operacional. Em Proc. da 7ª Int’l.Conf. em ASPLOS, páginas 74-83, 1996.
[Chen02] Chen, M. et al, “ Pinpoint: Problem Determination in Large, Dynamic Internet Services”, em preparação., 2002.
[CN01] Peter M. Chen e Brian Noble. Quando o virtual é melhor que o real. Em Proc. Oitavo Symp.on Hot Topics in Operating Systems (HotOS-VIII), Elmau, Alemanha, maio de 2001.
[Choi99] J. Choi, M. Choi e S. Lee. Um esquema de correlação de alarmes e identificação de falhas baseado em classes de objetos gerenciados por OSI. 1999 IEEE Int’l.Conf. em Comunicações, Vancouver, BC, Canadá, 1999, 1547-51.
[Elnozahy96] E. N. Elnozahy, D. B. Johnson e Y. M. Wang. Uma Pesquisa de Protocolos de Recuperação de Rollback em Sistemas de Passagem de Mensagens. Relatório Técnico CMU CMU TR 96-181, Carnegie Mellon University, 1996.
[EMC02] EMC TimeFinder, http://www.emc.com/products/software/timefinder.jsp.
[Fox97] A. Fox, S. Gribble, Y. Chawathe et al. Serviços de rede escalonáveis baseados em cluster. Proc. do 16º Symp.on Operating System Principles (SOSP 16), St. Malo, França, outubro de 1997.
[Fox99] Fox, A.; Cervejeiro, E. A. Colheita, rendimento e sistemas tolerantes escaláveis. Proc.s 7th Workshop on Hot Topics in Operating Systems, , Rio Rico, AZ, EUA, 29-30 de março de 1999. p.174-8.
[Garg97] S. Garg, A. Puliafito, M. Telek, K.S. Trivedi. Sobre a análise de políticas de rejuvenescimento de software. Proc. da 12ª Conferência Anual em Computer Assurance, junho de 1997, pp. 88-96.
[Gates02] Gates, e-mail da W. Miscrosoft, 15 de janeiro de 2002. Relatado no N.Y.times.
[Gillen2002] Gillen, Al, Dan Kusnetzky e Scott McLaron “O Papel do Linux na Redução do Custo da Computação Empresarial, white paper da IDC, janeiro de 2002, disponível em www.redhat.com.
[Gray78] J. Gray,: Notas sobre sistemas operacionais de banco de dados. Curso Avançado: Sistemas Operacionais 1978: 393-481.
[Gray86] J. Gray. Por que os computadores param e o que pode ser feito a respeito? Symp.on Reliability in Distributed Software and Database Systems, 3-12, 1986.
[Gray96] J. Gray, P. Helland, P. O Neil e D. Shasa. Os perigos da replicação e uma solução. Proc. do 1996 ACM SIGMOD Int’l.Conf. em Gerenciamento de Dados, 1996, 173–182.
[Gray02] Gray, J. O que vem depois? Uma dúzia de problemas de TI restantes, Turing Award Lecture, 1999
[Gribble00] S. D. Gribble, E. A. Brewer, J. M. Hellerstein e D. Culler. Estruturas de dados escaláveis e distribuídas para construção de serviços de Internet. Proc. do Quarto Simpósio sobre Projeto e Implementação de Sistemas Operacionais (OSDI 2000), 2000.
[Gruschke98] B. Gruschke. Gerenciamento Integrado de Eventos: Correlação de Eventos Usando Gráficos de Dependência. Proc. do 9º IFIP/IEEE Int’l.Workshop sobre Operação e Gerenciamento de Sistemas Distribuídos (DSOM98), 1998.
[Hennessy99] J. Hennessy, The Future of Systems Research, Computer, agosto de 1999 32:8, 27-33.
[HP02], Hennessy, J., D. Patterons, Computer Architecture: A Quatitative Approach, 3ª edição, Morgan Kauffman, San Francisco, 2002.
[Hitz95] D. Hitz, J. Lau, M. Malcolm. Design de sistema de arquivos para um NFS Server Appliance. Relatório Técnico de Dispositivo de Rede TR3002, março de 1995.
[Huang95] Y. Huang, C. Kintala, N. Kolettis, N.D. Fulton. Rejuvenescimento de software: análise, módulo e aplicações. Proc. 25th Int’l.Symp.on Fault-Tolerant Computing, junho de 1995, pp. 381-390.
[IBM 01]] IBM, Automonic Computing, http://www.research.ibm.com/autonomic/., 2001
[Jain88] Jain, A. e Dubes, R., () _Algorithms for Clustering Data. Prentice Hall, Nova Jersey. 1988.
[Kao93] W. Kao, R. Iyer e D. Tang. FINE: Um ambiente de injeção e monitoramento de falhas para rastrear o comportamento do sistema UNIX sob falhas. IEEE Transactions on Software Engineering, 19(11):1105-1118, 1993.

(1) Uma pesquisa de Mori para o Abbey National na Grã-Bretanha descobriu que mais de um em cada oito viu seus colegas intimidar o departamento de TI quando as coisas dão errado, enquanto um quarto dos jovens com menos de 25 anos viu colegas chutando seus computadores. Cerca de 2% afirmaram ter realmente batido na pessoa ao lado deles em sua frustração. Helen Petrie, professora de interação humano-computador na City University de Londres. diz: “Existem duas fases na fúria da Net - ela começa na mente e depois se torna física, com tremores, dilatação dos olhos, sudorese e aumento da frequência cardíaca. Você está se preparando para lutar, sem ninguém contra quem lutar.” From Net effect of computer rage, de Mark Hughes-Morgan, Associated Press, 25 de fevereiro de 2002.
(2) Caro Revisor: Semelhante ao artigo da OceanStore na última ASPLOS, este artigo está no início do projeto, mas apresenta as perspectivas e tem resultados iniciais para demonstrar a importância e plausibilidade dessas ideias potencialmente controversas. Notamos que a Chamada de Trabalhos diz que artigos de “Nova ideia” são encorajados; o comitê do programa reconhece que tais artigos podem conter uma avaliação significativamente menos completa do que artigos em áreas mais estabelecidas. O comitê também dará atenção especial a trabalhos controversos que estimulem debates interessantes durante a reunião do comitê. Esperamos que nossa nova e controversa perspectiva possa compensar a falta de medições de desempenho em um único protótipo integrado