Estratégia para Testes de Componentes de Banco de Dados Orientados a Objetos utilizando
Injeção de Falhas
Regina Lúcia de Oliveira Moraes
Dissertação de MestradoInstituto de Computação (IC)
Universidade Estadual de Cam inas (UNICAMP)
Estratégia para Testes de Componentes de Banco
de Dados Orientados a Objetos utilizando
Injeção de Falhas
Banca Examinadora:
Eliane Martins (Orientadora) IC-UNICAMP
Cláudia Bauzer Medeiros IC-UNICAMP
Taisy Silva Weber
Instituto de Informática - UFRGS Cecília Mary Fischer Rubira (suplente) IC- UNICAMP
Junho de 2003
Dissertação submetida ao Instituto de Computação da Universidade Estadual de Campinas, como requisito parcial para a obtenção do título de Mestre em Ciência de Computação,
M79!e
'"":.Ma CATALOGRÁFICA ELABORADA PELA
BIBLIOTECA DA UNICAMP
Moraes, Regina Lúcia de Oliveira
Estratégia para testes de componentes de banco de dados orientado a objetos utilizando injeção de falhas/Regina Lúcia de Oliveira Moraes-- Campinas, [S.P. :s.n.], 2003.
Orientador : Eliane Martins.
Dissertação (Mestrado) - Universidade Estadual de Campinas, Instituto de Computação.
l.Engenharia de software - Metodologia. 2.To!erância à falhas (Computação). 3.Banco de dados orientados a objetos. L Martins, Eliane. !L Universidade Estadual de Campinas. Instituto de Computação. 111. Título.
Estratégia para Testes de Componentes de Banco de
Dados Orientados a Objetos utilizando
Injeção de Falhas
Este exemplar corresponde à redação final de dissertação, devidamente e defendida por Regina Lúcia de Oliv·eim
pela Banca Examinadora.
Campinas, 29 de agosto de 2003.
Profu. Dra. Eliane Martíns
Dissertação apresentada ao Instituto de Computação da Universidade Estadual de Campínas, UNI CAMP, como requisito parcial para a obtenção do titulo de Mestre em Ciência de Computação.
TERMO DE APROVAÇÃO
Tese defendida e aprovada em 13 de junho de 2003, pela Banca
Examinadora composta pelos Professores Doutores:
~Profa.
Ora. Claudia Maria Bauzer Medeiros
IC- UNICAMP
Profa. Ora. Eliane Martins
IC- UNICAMP
Agradecimentos
À minha orientadora, Profa. Dra. Eliane Martins, pela amizade, pela paciência, pelo tempo que me dedicou, pelos conhecimentos que comigo oompartilliou e principalmente pelo incentivo e apoio durante todo o tempo em que estive envolvida no traballio de pesquisa e redação dessa dissertação. A ela devo muito, muito mais do que ela possa imaginar.
A Profa. Dra. Cecília Mary Fiscber Rubira, pelos valiosos conselhos que me auxiliaram a enteoder melhor diversos aspectos envolvidos nessa pesquisa.
Aos meus familiares, que me deram estimulo e apoio ao longo do meu traballio, e em especial às
minhas filhas, grandes mulheres, grandes amigas, grandes cérebros, que sendo a razão da minha
exisl:ência me deram força para enfrentar todas as dificuldades que a vida me reservou e me motivaram a superá-las.
Ao Nelson Guilherme Mendes Leme, por ter desenvolvido a ferramenta de injeção de falhas para que eu pudesse utilizá-la nesse experimento.
Ao amigo Daniel Roland Gullo, pelo valioso apoio na resolução dos problemas de configuração do ambiente de teste.
Ao aluno Roberto Torres, pela implementação inicial da interface da ferramenta.
A F abiana Cristina de Souza Alves, pela implementação das novas funcionalidades para o benchma!k 007 que encontramos no site do Ozone, pela correção da ferramenta de uyeção e sua interface.
Aos meus amigos, que muito contribuíram com seus incentivos, muitas vezes acreditando em mim
mais do que eu mesma e por terem proporcionado alguns momentos divertidos no decorrer desse trabalho.
À Universidade Estadual de Campinas (UNJCAMP), que tem sido parte da metade da minha
existência proporcionando todas as oportunidades para o meu desenvolvimento intelectual e profissional.
Às pessoas que me desafiaram e que muitas vezes me decepcionaram, pois assim me ensinaram a me recuperar de cada tropeço na estrada da vida.
... "Para não arrefecerdes, Imaginai que podeis vir a saber tudo; Para não presumirdes, Refleti que, por muito que souberdes, Mui pouco tereis cbegado a saber."
I recho do "Discurso no Colégio Anchieta" Rui Barbosa, Nova Friburgo, 1903
Resumo
A maioria dos software desenvolvidos atualmente, incluindo sistemas críticos, utiliza em algum momento software desenvolvido por terceiros ou do inglês, third-parties components. Em
especial, quase a totalidade dos sistemas desenvolvidos utiliza um gerenciador de base de dados que é adquirido de empresas especializadas nesse segmente. Como a segurança que se espera do fimciO!llllllelltc desses componentes é importanle, a injeção de falhas por software é uma ferramenta útil na sua validação, tendo se mostrado uma das formas mais eficientes para isso.
Nesse processo são introduzidas falhas, e observada a resposta do sistema quando em presença das falhas uyetadas. Para que se possa utilizar essa técnica, é necessário que se tenha à mão uma ferramenta que nos pernrita as falhas e monitorar o sistema sob teste para que possamos acompanhar o seu comportamento. Para a credibilidade desses restes, é interessante que se tenha uma estratégia que se possa segnir, objetivando a escolha de alguns requisitos necessários para a injeção: as falhas a injetar, onde injetá-las, a maneira de ativá-las, como coletar os resultados e determinar o sucesso ou insucesso do componente ao tentar resolver da maneira esperada o erro causado pela injeção.
Para nossos experimentos, escolhemos como componente rerceírizado um gerenciador de banco de dados orientado a objetos, o Ozone. Como aplicação, utilizada para ativar as falhas injetadas, utilizamos um benchmark desenvolvido para restes de desempenho desse tipo de componente, o Wisconsin 007. A Jaca, desenvolvida em trabalho anterior de mestrado do Instituto de Computação, foi a ferramenta escolhida para viabilizar os restes por irgeção de falhas, permitindo injetar falhas por software.
Uma das contribnições desse trabalho foi, a proposta de uma estratégia para a validação de componentes 00. Outra contribuição foram os restes da ferramenta de injeção, bem como, o aparte de
Abstract
Title: §trategy for Ol>ject Oriente<! Datai>Wle 'fest using Software Fault J:njed:ion
The majorily of software curremly developed - includíng criticai systems - utilize Jhird-party components. Further, almos! all systems use Database Management Systems lhat are acquired from fl111lS specialíze in this sector. Given lhe security expected from these components, software fault injection is a useful and efficient validation tool.
The process comprises lhe introduction of faults and observation of system replies wlren in presence of injected faults. To use this technique ít is necessary to nave a tool that allows for lhe injection offaults and lhe monitoring oflhe system under test in order to accompany its benavior. To achieve credibilily lhese tests need a strategy lhat permits lhe choice of some necessary requirements for lhe injection. Among lhese requirements are wnat faults to inject, wbere to inject how to activate lhem, how to oollect results and how to determine lhe component's success or faílure when tryíng to solve lhe problem caused by lhe injections lhrough lhe expected manner.
For lhe experiments conducted, Ozooe an objectoriented database management system -was chosen as lhe Jhird-party component. We nave used Wisoonsin 007, a benchmark developed for performance tests on lhese types of components, as lhe application to activate lhe injected faults. Jaca, that was developed previously at lhe Institute of Computing, was lhe chosen tool to make feasible lhe injection tests. It allowed for software fault injection.
One ccnttibuition of lhis work is lhe proposed validation strategy for 00 components. The other contnbnition is the injection tool' s tests, its correcítons and improvements proposed
Índice
Ll. CmJTEXTO ... . .. ... ! L2. MoTIVAÇÃO... .. ... . .. ... .3 !.3. ÜBJETJVOS. .. ... . .. ... ..4 !.4. ComRJBmçõES ... .. . ... .5 !.5. TEIU.i!NOLOG!A ... . . ... .5 !.6. ÜRG&'IlZAÇÃO DO TEXTO ... . .. 6 INJEÇÃO DE F ALHAS.-···-··-·-···-··-···-·-·-···-···-··-··-··-·-···-···-····-····-··-·-·-·-··9 ll.l. OORODUÇÃO... ... ... ... .. ... 9!I. 2. ABORDAGENS DE INJEÇÃO DE FALHAS ... ! 0
li. 3. FERRAMENTAS DE INJEÇÃO DE FALHAS ... !4
II3.1. Generalidades ... l4 1!.3.2. Xaptic>n. II.3.3. FIRE ... 15 IL3.4. ComFIRM ... 16 JL3. 4. FIDe ... ... 16 J/.3.5. TAMER ... 17 Il.4. REsuMo ... 18
FERRAMENTA DE INJEÇÃO DE FALHAS JACA·-··--·-··-·-·-·-··-··-··-·-·-··-·-·-·-·---··-·-·-19
Ill.l. GENERALIDADES ... .. .. ... 19
!II.2.ARQ1:JITETURA DA FERRAMENTA JACA ... 20
Ill.3. REFLExÃO COMPVT ACIONAL NA JACA ... 22
Ill.4. UTJLIZA.NDO A JACA... ... . ... 23
Ill.5. A INTERFACE GR<Í.FICADAJACA. ... ... ... ... .. ... 26
Ili.6. REsUMO... ... ... ... ... .. .... .31
GERENCIADORES DE BANCO DE DADOS ORIENTADOS A OBJETOS ·-··-·-·-··--··-·---33
!V. L GENERALIDADES ... .. . ... 33
IV.2. CONCEITOS DE BANCO DE DADOS ... . . ... 33
IV.J. GERENC!ADORDEBASEDEDADOSORIE."i'TADOAOBJETOS ... .38
IV.4. ESCOLHA DO GERENCIADOR DE BASE DE DADOS OR!EN'T ADO AOBJETOS ... 44
!V.5. GERENCLIDOR ÜZON'E ... .45
IV.6. REsUMo... ... .. ... .48
.ESTRATÉGIA PARA TESTES COM INJEÇÃO DE ERROS·-··-·--·----·---··-·-·-·-·--·--49
V.l. GENERALIDADES ... 49
V.2. ESTR\.TÉGIAPARA SELEÇ.Ã.O DOS OBJETOS A INJETAR.... .. ... 50
V.3. 0 MODELO F ARM ... 53 V.3.1. O conjunto A ... , ... 54 V. 3. 2. O conjunto F ... 55 V. 3.3. O conjunto R ... 56 V.3.4. O conjunto M ... , ... 56 V.4. REsUMO... ... ... ... . ... .58 B.ENCHMARK WISCONSIN 007·-···-···-··-··-·-···-·-···-·-···-···-··-··61 VI.!. lNTRODUÇ.:\0 ... . Vl.2. CARACTERÍSTICAS DO BENCHMARK ... . Vl.3. 0 PROJETO DO BENCHMARK .... ... 61 .. ... 61 .. ... 62
VIS APREsENTAÇÃODOSREslJLTADOS ... 67
VI.6. REsuMo ... 68
TESTES COM APLICAÇÃO REAL·-···-··-···-···-···-···-···-···69
VIU. SELEÇÃODOSlTENSAlNJETAR... ... . ... 69
VIJ.2. lDENTlFJCAÇÃO DOS MÉTODOS E ATRIBUTOS A SEREM INJETADOS .... . ... . ... . .... 70
VIl.3.lDENTlFICAÇÃODOSVALORESASEREMJNJETADOS . ... .. . . ... .. 72
VIlA. DADOS COLETADOS.. . ... 72
VIl5. CA'W' A};"HA DE !NJEÇ.'i.O pARA A v ALLWÃO DE DEsEMPEN"HO. . ., ... ., ... 73
VIL6. CAMPANHADElNJEÇÃOPARAÜBSERVAROCOMFORTAMENTODOÜZONE ... .,.,.,.,., ... 81
Vl16.1. Procedimentos para Verificação das Propriedades ACJD .. ., ... ., 82
Vl/.6.2. Caracterização dos Defeitos e Seqüência de Execução ... 83
Vl/.6.3. Testes e Resultados ... 84
VII.7. AVALIAÇÃODAESTRATÉGIA. ... 89
VIJ.8. REsu"MO. ... ... ... . ... 89
CONCLUSÕES E TRAIIALHOS FUTUROS ···-···-··-·-···-·-·-···-···-··-··-··-·-···-···-91
VIII. L CONCLUSÕES ... 91
VIII.2. TRABALHOS FUTUROS ... . . ... 93
REFERÊNCIAS
BIBLlOGRÁFICAS.-··-·-·-··-·-···-··-··-···-··-···-····--···-··-···-··-···95
APÊNDICE
A
·-··-·-·-··-·-··-·-··-··-··-·-·-··--··-·-····--···-·-··-·-··-·-··-··-··-·-·-··--··-·-··-·-··-·-·99
APÊNDICE B--···-··-·-··-···-···-·-··-·-···-····-···-·-···-···-···-·-··-·-··-·-··-··-··-··103
APÊNDICE
C--··-·--··-·-··-·-··-··-·-·-·-··-·-··-·-··---·---·-·-··-·-·-··----·-··-·-·-·---··-··-··107
ARTIGOS GERADOS
A l'ARTm DESSE TRAIIALH0.-···-··-·-···-···-···-···-··-··-·107
ANEXO I ·-··-·-·-··-·-··-·-·-··-··-·-·-··-·-··-···-··-··-·-·-··-·-··-·-··-··-··-·-·-··-·-··-·-·-··-··-····--·1 09
ANEXO II--··-·-·-···-··-·-··-··-···-·-··-···-·-··-··-···-···-··-·-···-···-··-·-···---··-····-··11 I
'
Indice de Figuras
Fig. 1: Diagrama da Arquitetura da Jaca 21
Fig. Esquema da Ferramenta Jaca ... .
Fig. 3: Interface da 26
Fig. 4: A interface gráfica da Jaca- escolha da classe de objetos a ser injetada ... 28
Fig. 5: A interface gráfice da Jaca - escolha do atributo onde se dará a injeção ... 29
Fig. 6: A interface gráfica da Jaca- escolha da operação e das classes monitoradas .. 30
Fig. 7: Diagrama de estado de uma transação. [26] ... 35
Fig. 8: Arquitetura de um Gerenciador de base de dados orientado a objetos [38] ... 40
Fig. 9: Aspectos de um SGBDOO [64]. ... 41
Fig. 10: Tarefas para a Persistência de Objetos ... 43
Fig. 11: Arquitetura Básica do Ozone com servidor remoto [51] ... 46
Fig. 12: Objeto Composto e seu documento associado [8] ... 63
Fig. 13: Estrutura de um módulo [6] ... 64
Fig. 14: Interface do Ozone, onde são apresentados os clusters 75 Fig. 15: Interface da Jaca durante a criação dos objetos utilizando a injeção de erros .. 75
Fig. 16:1nterface do Ozone apresentada na execução de um Query Match ... 76
Fig. 17: Interface da Jaca apresentada na execução de um query match ... 76
Fíg. 18: Interface do Ozone apresentada na execução de um Query Traversal. ... 77
Fig. 19: Desempenho da funcionalidade create ... 80
Fig. 20: Desempenho da funcionalidade query Match ... 80
Fig. 21: Desempenho da funcionalidade query Treversa/. ... 80
Fig. 23: Comparação da Média dos Tempos de Execução do Benchmark ... 81
Fig. 24: Resultado dos Testes efetuados na Primeira Campanha ... 88
Fig. 25: Distribuição dos Testes efetuados na classe Benchmarklmpl ... 88
Fig. 8.1: Relatório de Saída da ferramenta RSM para a classe Benchmarklmpl ... 104
Índice de Tabelas
Tabela 111: Formatos dos Registros do Arquivo de Especificação das Falhas ... 25
Tabela V.1: Métricas CK ... 51
Tabela V.2: Atributos FARM e os objetivos da validação da tolerância a falhas ... 54
Tabela VI: Panãmetros do Benohma!'K Wísoonsin 007 [7] ... 65
Tabela VIl. i: Identificação das classes a injetar ... 70
Tabela Métodos das Classes a serem injetados pela ferramenta Jaca ... 71
Tabela Vll.3: Locais Injetados (tabela parcial) ... 72
Tabela V11.4: Dados Coletados ... 73
Tabela Vll.5: Tempos Apurados nos Testes de Desempenho ... 79
Dissertação de Mestrado Estratégia para Testes de Banco de Dados Orientados a Objetos utilizando Injeção de Falhas
Capítulo I:
Introdução
Contexto.
Uso de sistemas computacionais. Sistemas computacionais têm tido uso em diversas áreas, atendendo uma enorme gama de atividades. Algumas vezes, estes sistemas auxiliam uma dada atividade humana, mas em muitas outras, eles tem um papel essencial, uma vez que sem eles a atividade planejada não seria possível de ser realizada. Alguns exemplos do nosso cotidiano podem ser citados, tais como os modernos aviões de transporte de passageiros ou cargas que são atualmente comandados por computadores, e em caso de falha destes, o piloto, dificilmente terá condições de controlar a aeronave. exemplo, os sistemas bancários, onde os grandes sistemas computacionais usados pelas instituições financeiras são cruciais para o controle de suas movimentações. Além disso, todos os sistemas precisam de um meio de armazenamento que, por sua vez, precisa ser igualmente seguro, atender algumas propriedades exigidas e prover mecanismos de recuperação quando houver falhas inesperadas.
Problemas. Assim, um sistema computacional que, subitamente, cesse de realizar suas funções, pode causar problemas seríssimos, como por exemplo, a queda de aeronaves ou a interrupção das operações financeiras, causando perdas de vidas humanas ou prejuízos financeiros de grande monta. Normalmente, uma falha é a responsável por tais interrupções na prestação dos serviços feitos por um sistema computacionaL Criar aplicações a partir de componentes, não é algo novo, esse enfoque tem estado em uso durante vários anos e tem aumentado, significativamente, sua importância no desenvolvimento de software. Um defeito em um componente, tanto de hardware como de software, consiste na apresentação de um comportamento anômalo desse componente dentro do sistema. Como a utilização de componentes adquiridos de terceiros (em inglês, third-parties components) está se tornando cada vez mais necessária, devido à necessidade de software para controle de atividades complexas, que exigem uma gama bastante grande de conhecimentos, precisamos ficar atentos ao nível de correção desses componentes. Precisamos dispensar a estes tanta atenção quanto a que dispensamos aos componentes desenvolvidos internamente, uma vez que componentes terceirizados estão sendo utilizados muito freqüentemente em aplicações críticas. Devido à complexidade imposta aos sistemas atuais, atributos de segurança no funcionamento, confiabilidade,
Dissertação de Mestrado Estratégia para Testes de Banco de Dados Orientados a Objetos utilizando Jnjecão de Falhas
disponibilidade, deixaram de ser exigências específicas de sistemas críticos, passando a integrar os requisitos de todos os sistemas computacionais. É esperado que os sistemas em operação continuem a fornecer o serviço proposto, mesmo na presença de falhas, devendo possuir um Mecanismo de Tolerância a Falhas (MTF), que irá permitir que o sistema dê uma resposta esperada mesmo quando falhas ocorrem, sendo estes denominados sistemas tolerantes a falha.
Testes. Implementar um MTF para se ter um sistema tolerante a falhas não é o bastante. É preciso que o sistema seja testado adequadamente, para verificar se o MTF irá tratar a ocorrência das falhas, como previsto na especificação do sistema. assim o sistema não irá apresentar comportamento inesperado, e;,.itando-se possíveis prejuízos. Dessa forma, é fundamental testar sistemas e, principalmente, testar os sistemas tolerantes à falha. Mas, como devemos proceder para testar os componentes adquiridos de terceiros? Uma falha nesses componentes poderá ser desastrosa, quanto uma falha em qualquer outro componente, que tenha sido desenvolvido internamente. Um agravante para teste de um componente adquirido de terceiros, é que praticamente em sua totalidade não temos acesso ao código fonte e dificilmente teremos informações de seus mecanismos de tolerância a falhas, que são relevantes para que possamos atingir a especificação do sistema que o utiliza. Saber que tipo de teste utilizar e como proceder para encaminhar esses testes é um desafio que precisamos vencer.
Teste por Injeção de Falhas. Uma abordagem que tem se mostrado bastante eficiente para se testar esses sistemas, é o uso de Injeção de Falhas. Injeção de Falhas é uma técnica de teste, em que se procura produzir ou simular a presença de falhas e se observa o sistema sob teste para se verificar qual será sua resposta nessas condições. Acelerando a ocorrência de erros e defeitos, essa técnica é uma valiosa abordagem para validar sistemas onde a segurança é um requisito indispensável, avaliar o impacto da detecção desses erros, como também, o impacto dos mecanismos de recuperação sobre o desempenho do sistema. Com isso, se consegue uma avaliação mais precisa do comportamento do sistema na presença de falhas e se, eventualmente, alguma falha não for tratada adequadamente, isso será detectado com o teste por injeção de falhas. O sistema poderá, então, ser corrigido, antes que seja colocado em operação.
Ferramentas de Injeção de Falhas. Para que possamos injetar falhas precisamos de ferramentas apropriadas. Essas ferramentas executam o sistema sob teste e produzem ou simulam a presença de falhas, monitorando o sistema para verificar qual é seu comportamento. Para que tenhamos sucesso nos testes através da injeção de falhas, a ferramenta utilizada deverá ser eficiente tanto no momento de injetar as falhas quanto ao
Dissertação de Mestrado Estratégia vara Testes de Banco de Dados Orientados a Objetos utilizando Injeção de Falhas
reportar os resultados dos testes e o comportamento do sistema ao tratar as falhas ou erros injetados.
Estratégia para Testes de Componentes Terceirizados. Como citamos anteriormente, para se conduzir os testes de componentes terceirizados, precisamos definir uma estratégia a seguir, uma vez que os testes deste tipo de componente diferem dos testes de componentes desenvolvidos pelas equipes internas, dos quais temos pleno controle e
componente terceirizado que esteja sendo utilizado como parte de soluções reais.
I.2.
Motivação.
Validar os mecanismos de injeção oferecidos pela Jaca, utilizando uma aplicação real. Jaca é uma ferramenta para injeção de falhas por software, cuja implementação foi escrita na linguagem Java. Oferece mecanismos para injetar falhas de alto em sistemas orientados a objetos. Permite uma fácil adaptação, atendendo à especificação de qualquer sistema Java com um mínimo de reescrita, e não necessita do código fonte do sistema sob teste. Monitora os sistemas para verificar se as respostas por ele produzidas estão dentro dos padrões esperados, mesmo em presença de falhas. Desenvolvida, na própria universidade, num trabalho de pesquisa anterior a esse, foi validada com um estudo de caso bastante simples. Assim sendo, a importância de se validar a ferramenta, utilizando uma aplicação real é essencial para que possamos comprovar a confiabilidade nos mecanismos que ela nos fornece. Escolhemos para isso um componente terceirizado que gerencia um banco de dados orientado a objetos, cuja implementação foi feita utilizando a linguagem Java, o Ozone. Um benchmark para testes de desempenho, o Wisconsin 007, foi aqui utilizado como ativador das falhas injetadas.
Estratégia para testes por Injeção de Falhas. A utilização de componentes terceirizados tem tido uma crescente utilização nos ambientes de desenvolvimento de software e, em especial, a utilização de gerenciadores de banco de dados. Como a confiabilidade que se espera desses componentes, é importante e muitas vezes essencial, a injeção de falhas por sofuvare é uma ferramenta útil para a verificação desses sistemas, visando a eliminação de falhas. Assim, a falta de uma estratégia, que auxilie a condução dos testes desses componentes, utilizando injeção de falhas, é um fator que dificulta esses testes e impede muitas vezes a obtenção de resultados confiáveis.
A importância desses pontos no desenvolvimento de sistemas atuais nos motivou a desenvolver esse trabalho.
Dissertação de 1Y1estrado Estratégia para Testes de Banco de Dados Orientados a Obietos utilizando lnieção de Falhas
L3. Objetivos.
Definir uma estratégia para validação de componentes terceirizados usando a Jaca. Quando se pretende trabalhar com injeção de falhas, algumas etapas devem ser cumpridas. Primeiramente, precisaremos configurar a ferramenta, preparar a injeção, aplicar a injeção e analisar os resultados. Para nossos estudos não foram necessárias configurações adicionais àquelas previamente existentes. Para a fase de preparação da injeção nos baseamos no modelo F ARM, que caracteriza os principais atributos da injeção de falhas[1][47]. A injeção de falhas é caracterizada por um domínio entrada e um domínio de saída. O domínio de entrada corresponde a um conjunto de falhas a injetar F e um conjunto de ativações A que especifica as entradas destinadas a exercitar o sistema e assim, ativar as falhas injetadas. O domínio de saída é caracterizado por um conjunto de dados coletados R e um conjunto de medidas M derivadas da análise e
tratamento dos Assim, os critérios a serem na determinação
das entradas (F e A), na coleta das saídas (R) e no cálculo das medidas (M), precisam ser estabelecidos. Nosso ponto de partida para o experimento é definir os conjuntos do modelo
FARM.
Determinar se o gerenciador garante a integridade e a consistência em presença de falhas. Transações são agrupamentos de operações que atendem determinadas propriedades, propriedades essas denominadas ACID, Atomicidade, Consistência, Isolamento e Durabilidade. Essas propriedades precisam ser respeitadas para que a integridade dos objetos armazenados seja garantida. Na ausência de falhas todas as transações completam-se com sucesso. Entretanto, nem sempre uma transação pode completar-se com sucesso, pois pode ser afetada por falhas tanto de hardware quanto de software. Através da injeção de falhas por software iremos testar se essas propriedades serão garantidas, mesmo em presença das falhas injetadas.
Avaliar o impacto no desempenho causado pela ativação da Jaca, na aplicação sob teste. Quando utilizamos o benchmark para ativar as falhas injetadas pela ferramenta é possível que tenhamos uma perda de desempenho do sistema sob teste, pois a cada injeção a ferramenta interrompe o processamento para injetar a falha e para monitorar as classes destacadas. Um dos objetivos desse trabalho é avaliar qual é o impacto no desempenho do sistema sob teste causado pela ferramenta de injeção.
Díssertação de Ji;Jestrado Estratégia para Testes de Banco de Dados Olientados a Objetos utilizando Injeção de Falhas
I.4. Contribuições.
As contribuições dadas por este trabalho são:
• Avaliação e validação da ferramenta de injeção de falhas, Jaca e a implementação de sua interface gráfica, para que se possa, em trabalhos futuros, implementar melhorias, corrigir eventuais falhas, visando a utilização da ferramenta em larga escala.
• Disponibilizar uma estratégia a ser seguida por pessoas interessadas em testar componentes terceirizados, especialmente Sistemas Gerenciadores de Banco de Dados, utilizando injeção de falhas por software através de uma ferramenta de injeção, particularmente a Jaca.
• Comprovar a utilidade da Jaca para testes por injeção de falhas por software para componentes terceirizados.
• Constatação da utilidade da Jaca também para validar gerenciadores de banco de dados não orientados a objetos.
• Correção da ferramenta para a correta gravação do log e detecção de falhas que precisam ser corrigidas.
• Validação do gerenciador Ozone e a constatação de defeitos nas transações, mais precisamente com roll back das transações.
• Constatação do pequeno impacto no desempenho provocado pela intrusão da Jaca.
• Complementação da versão do benchmark Wisconsin 007, cuja implementação utiliza o Ozone e foi disponibilizada pela equipe de desenvolvimento desse componente.
• Verificar a eficiência dos mecanismos de injeção e monitoramento da Jaca e sugerir modificações que possam melhorar esses mecanismos e sua usabilidade.
Ls.
Terminologia.
Ainda não há um consenso sobre a terminologia a ser utilizada no campo de Tolerância a Falhas. Já ocorreram várias discussões a esse respeito nos workshops e simpósios feitos na área, porém um padrão ainda não emergiu. Para e-vitar enganos nesta dissertação, estamos utilizando os termos abaixo com os seguintes sentidos, baseados em [40]:
Dissertação de Mestrado Estratégia para Testes de Banco de Dados Orientados a Objetos utilizando Injeção de Falhas
• Especificação é uma descrição da função ou sen,iço (comportamento) esperado do sistema, descrevendo a funcionalidade original para a qual o sistema foi projetado.
• Falha (fault): causa suposta ou constatada de um erro do sistema.
• Erro (errar): sendo encontrada uma falha dentro de um dado processamento do sistema, essa falha levará a uma modificação no estado
causado pela falha é denominado erro.
sistema. Esse estado
• Defeito (failure): tendo a falha levado a um erro, esse erro por sua vez fará com que o sistema apresente um defeito. Um sistema apresenta um defeito quando o sen'lço que deveria oferecer não está de acordo com o que tinha sido especificado.
• Validação: a validação da segurança no funcionamento é um processo no qual
se retiradas as falhas do sistema e se de
confiabilidade, disponibilidade, eficiência dos MTFs e outros.
1.6. Organização do texto.
A presente dissertação está organizada da seguinte forma:
• O capítulo II ("Injeção de Falhas") explica o próprio conceito de Injeção de Falhas, uma das bases teóricas desse trabalho.
• O capítulo III ("Ferramenta de Injeção de Falhas Jaca") expõe a ferramenta Jaca, para a qual mostramos suas particularidades e a maneira de utilização. • O capítulo IV ("Gerenciadores de Banco de Dados Orientado a Objetos") mostra
um dos trabalhos feitos neste projeto, que foi o estudo de Gerenciadores de Banco de Dados Relacionais, Relacionais Estendidos e Orientado a Objetos. • O capítulo V ("Estratégia para Testes com Injeção de Erros") apresenta os
conceitos do modelo F ARM que caracteriza os testes por injeção de falhas, constituindo seus principais atributos e descreve a estratégia a seguir, quando se decide utilizar testes por injeção de falhas de alto níveL
• O capítulo VI ("Benchmark Wisconsin 007'') descreve o benchmark utilizado como ativador das falhas injetadas pela Jaca.
• O capítulo v1I ("Testes com Aplicação Real") exibe os rJ;sultados experimentais obtidos nos testes feitos com o benchmark e o banco de dados orientado a objetos, utilizando a ferramenta JACA
Dissertacão de Mestrado Estratégia para Testes de Banco de Dados Orientados a Obietos utilizando Injeção de Falhas
• o
("Conclusões e Trabalhos Futuros") discute os resultados obtidos neste projeto e sugere possíveis trabalhos futuros que poderiam ser feitos.• O capítulo IX ("Referências Bibliográficas'') mostra as referências bibliográficas pesquisadas na execução deste trabalho.
Dissertação de Ivf estrado Estratégia para Testes de Banco de Dados Orientados a Obietos utilizando Injeção de Falhas
Capitulo II:
Injeção de Falhas
II.L
Introdução.
O papel dos sistemas computacionais, nos dias é de grande importância e coloca-nos numa posição de total dependência, quando necessitamos realizar determinadas tarefas do nosso cotidiano. Quando sistemas computacionais são indispensáveis para gerenciar áreas críticas, não se pode permitir que comportamentos inesperados desses sistemas coloquem em risco vidas humanas, patrimônios ou investimentos.
Os sistemas que operam nessas áreas criticas são chamados sistemas com segurança no funcionamento (dependable systems), isto significa que os usuários desses sistemas (humanos ou fisicos) podem confiar no serviço (comportamento) provido por esse sistema.
das que esses sistemas devem apresentar é a Tolerância a Falhas, que
faz com que esse sistema, mesmo na presença de falhas, apresente uma resposta que atenda as especificações do sistema.
Uma falha ativa pode ser tanto uma falha interna que não tinha sido ativada, como uma falha externa. Um erro pode permanecer latente, isto é, sem ser reconhecido como tal, ou pode ser detectado por um Mecanismo de Tolerância a Falhas (MTF), cujo intuito é evitar que falhas ocorram durante a fase operacional. Um erro também pode se propagar, criando novos erros. Quando um erro afeta o serviço realizado por um componente, um defeito de componente ocorre [37] [44].
A utilização de sistemas tolerantes a falhas tem crescido vertiginosamente e, conseqüentemente, tem também crescido a importância de se testar esses sistemas e, principalmente, testar os mecanismos de tolerância a falhas, implementados por eles. Assim, algumas técnicas de teste de sistemas confiáveis foram desenvolvidas e, entre elas, uma que tem se tornado mais popular é chamada Injeção de Falhas. Essa técnica de validação experimental pode ser aplicada nos diferentes estágios do desenvolvimento e opera através da introdução deliberada de falhas em um sistema para acelerar a ocorrência de erros ou defeitos e, em seguida, observar seu comportamento, verificando se o mesmo continua a operar, como esperado, dando maior confiabilidade sobre o funcionamento do sistema sob teste.
Injeção de Falhas tem sido usada para assegurar a confiabilidade de sistemas tolerantes a falhas desde 1970 pela indústria, segundo [17], com o intuito de medir cobertura (probabilidade de efetuar com sucesso detecção e recuperação de erro) e latência
Dissertação de 11,.1estrado Estratégia para Testes de Banco de Dados Orientados a Objetos utilizando Injeção de Falhas
de mecanismos de tolerância à falhas. Nos meios acadêmicos, começou a ser examinada em meados da década de So, e de lá para cá tem se veriílcado uma grande expansão junto aos pesquisadores, inclusive sendo aplicada a produtos que não necessitam ser tolerantes a falhas, mas objetivam o aumento da conílabilidade [15] e a quantificação de riscos do O desenvolvimento de um sistema, com segurança no funcionamento passa pela utilização de um conjunto de métodos que podem ser classificados como meios de obtenção da segurança no funcionamento- tolerância à falhas e prevenção de falhas (como impedir a ocorrência ou a introdução de falhas) e meios para a validação da segurança no funcionamento- eliminação de falhas (como reduzir o número e a severidade das falhas) e previsão de falhas (como estimar a presença, a criação e as conseqüências das falhas), tarefas para as quais os testes, por injeção de falhas podem ser bastante úteis [68].
Uma das primeiras formas de injeção de falhas utilizadas foi a injeção de falhas por mutação de código [23], que era para identificar os melhores conjuntos de casos de testes ou para estudar o processo de propagação de erros [25]. Mais recentemente, a injeção de falhas por software tem despertado bastante interesse, uma vez que, seu foco é validar os mecanismos de tolerância à falhas ou avaliar a maneira como os sistemas se comportam em presença das falhas injetadas. Nas seções seguintes, serão mostradas injeção de falhas, injeção de falhas por software e uma visão das ferramentas utilizadas para injetar falhas.
II.2. Abordagens de Injeção de Falhas.
Injeção de falhas pode ser aplicada a diferentes fases do ciclo de vida de um sistema, utilizando diferentes formas de aplicação, sendo a mais comum injeção de falhas por simulação, por hardware e por software.
Injeção de Falhas por simulação. Esta técnica é amplamente utilizada pela comunidade de testes de circuitos e de projeto de sistemas, sendo que as falhas são introduzidas num modelo do sistema alvo, que pode representar desde um componente até um sistema completo. O nível de abstração pode variar desde uma representação funcional do sistema até uma representação do mesmo em termos de portas ou transistores [22]. Um grande número de ferramentas já foi desenvolvido, já que injeção de falhas por simulação é útil para avaliar a segurança no funcionamento (dependability) do sistema nas primeiras fases do desenvohimento. Simulação também tem a vantagem de proporcionar grande controle e observação das falhas injetadas, quando comparado com injeção num protótipo ou sistema final, no qual o grande nível de integração entre dispositivos e tecnologias de empacotamento muito denso pode limitar a acessibilidade do modelo do sistema, de
Dissertacão de Mestrado Estratégia para Testes de Banco de Dados Orientados a Objetos utilizando Injeção de Falhas
maneira a permitir que os resultados obtidos possam ser representativos. Um dos problemas nesse tipo de injeção é a construção de um modelo que seja fiel à estrutura e/ ou comportamento do sistema. Outro problema é a aplicação de modelos de falhas representativos. Em se tratando de componentes a larga escala de integração, nem sempre é uma descrição detalhada de sua estrutura interna para que se possa obter a precisão necessária. Injetar falhas em um protótipo ou versão operacional de um sistema (falhas no hardware ou no software), é útil em complemento à injeção de falhas por simulação.
Injeção de Falhas por hardware. Nesse método, falhas são originadas de algum hardware especial, projetado especialmente para esse propósito. Consiste geralmente na aplicação de falhas físicas diretamente nos pinos dos circuitos integrados. Por exemplo, se um processador espera receber um sinal "um" em um pino específico, esse hardware especial iria injetar um sinal "zero" nesse e o processador seria observado. Existem vários métodos para injetar falhas de hardware: pela alteração de níveis lógicos em pinos de circuitos integrados [47], bombardeamento por íons pesados [31], pela alteração de níveis de suprimento de força, submissão a radiações eletromagnéticas, entre outros. Esses métodos são adequados para verificar a eficácia de mecanismos de tolerância a falhas implementados em hardware. Apesar desse tipo de injeção ser aplicável nas fases finais do desenvolvimento de um sistema, quando já se dispõe de um protótipo do mesmo, apresenta como principais vantagens: permitir a validação de um protótipo que é próximo do produto final, permitir a observação do efeito de falhas reais sobre o sistema e permitir a validação global do sistema, integrando tanto hardware quanto software. Uma das principais desvantagens é o não-determinismo, no sentido que não se pode determinar nem o número e nem a localização dos erros que são gerados, impossibilitando a capacidade de repetição dos experimentos.
Injeção de Falhas por software - Nesta técnica, falhas lógicas são introduzidas em um protótipo do software do sistema, para simular tanto falhas de software (internas), como falhas de sistemas externos ao software, mas conectados a este através de interfaces [69]. Falhas internas representam falhas de projeto e implementação, tais como variáveis ou parâmetros que estão errados ou não inicializados, atribuições incorretas ou verificações incorretas de condições. Falhas externas representam todos os fatores externos que não estão relacionados com falhas no código alvo, mas alteram o estado do software de algum modo. As falhas consideradas na maioria dos estudos nesta área, conseqüência de falhas de software, são as falhas de memória (alteram o conteúdo de posições de memória -programa ou dados), de processador (afetam o conteúdo de registradores, resultado de
Dissertação de Mestrado Estratéaia para Testes de Banco de Dados Orientados a Objetos utilizando lniecão de Falhas
caJcw.us, fluxo de controle ou código de instruções), de barramento (afetam as linhas de endereçamento ou dados que estão sendo transmitidos pelo barramento) e, no caso de sistemas distribuídos, as falhas de comunicação (afetam mensagens que são transmitidas através de um canal de comunicação que podem ser perdidas, alteradas, duplicadas ou entregues com atraso) [48]. Recentemente, tem preocupação com as conseqüências de falhas de sofuvare, acreditando serem estas a grande causa de defeitos em campo. Para se aplicar essa técnica, não é preciso hardware especial, e os testes podem ser mais facilmente controlados e observados. Devido a essas vantagens, de Falhas por software tem se tornado mais popular entre os desenvolvedores
falhas.
sistemas tolerantes a
Neste trabalho a Injeção de Falhas por Software foi a técnica utilizada e a seguir serão apresentadas as abordagens desta técnica.
Os mecanismos que podem ser utilizados para se injetar falhas por software podem ser classificados em três categorias, segundo [ 6o ]. A .injeção ativa é por um processo especial executado concorrentemente com os processos que fazem parte do sistema sob teste, podendo injetar falhas de memória em ambientes, onde não haja proteção contra acesso externo. A .injeção por alteração de :fluxo de controle é utilizada para alterar o comportamento funcional do sistema sob teste e, quando ativada, executa uma seqüência alternativa de instruções, de modo que a função corrente seja executada incorretamente. A .injeção por alteração de código é utilizada para injetar falhas em áreas do programa às quais um processo externo não pode ter acesso. A execução da aplicação sob teste é interrompida e em seu lugar é executado um código que insere falhas em várias partes do sistema, tais como, processadores e memória.
Essa alteração pode ser estática, quando feita em tempo de compilação, ou dinâmica, quando feita em tempo de execução. Na alteração estática, as falhas são introduzidas no código fonte ou assembly do programa alvo, e consiste na alteração de instruções do programa. Não precisa de software extra durante a execução para injetar falhas, não causando perturbação no sistema alvo durante a execução, porém, o modelo de falhas que pode ser injetado é limitado à falhas de sofuvare e conseqüências de falhas permanentes de hardware. Na alteração dinâmica, código extra é necessário para injetar falhas e monitorar seus efeitos e, também, é requerido um mecanismo para disparar a injeção de falhas. Para a alteração dinâmica pode-se utilizar os seguintes métodos: [32] [42]
• Modo traço (trace mode), uma rotina de depuração que roda em modo supervisor é executada antes de cada instrução do programa sob teste. Este por sua vez, é executado
Dissertação de Mestrado Estratégia para Testes de Banco de Dados Orientados a Objetos utilizando Iniecão de Falhas
passo a passo. Uma vez que a rotina de depuração roda em modo supervisor, ela terá acesso a toda a memória do programa e a todos os registradores visíveis ao programa. O modo traço encontra-se disponível em microprocessadores ou depuradores.
• Time out, nesse método a injeção de falhas é disparada a cada evento de time-out, que
é gerado por um timer de hardware ou software. Não requer modificação no programa e tanto a injeção quanto a monitorização podem ser implementadas como parte de
uma de interrupção.
• Exception/Traps, nesse método as falhas são disparadas por ocasião da ocorrência de alguns eventos, tais como a execução uma certa instrução ou o acesso a uma determinada posição de memória, sendo assim, baseado em interrupções causadas por exceções de hardware ou sofuvare.
• Processo especial é utilizado e tem o privilégio de acessar o espaço de memória do programa sob teste, injetando as falhas e observando seus efeitos.
• Inserção código, onde trechos de código são adicionados ao programa sob teste, permitindo que a injeção de falhas ocorra, antes da execução de uma dada instrução. Dessa forma, o código de injeção de falhas é parte do programa alvo e roda em modo usuário, e não em modo supervisor ou algum modo privilegiado.
Um problema a ser considerado quando se utiliza o mecanismo dinâmico de injeção, é o fato de serem eles intrusivos, uma vez que sua execução não é transparente para o sistema alvo, alterando, muitas vezes de maneira bastante significativa, seu desempenho. Dessa forma os resultados obtidos são afetados, devido ao overhead causado pela inserção do código do injetor de falhas. As ferramentas de injeção, além de interferirem no sistema para introduzir os erros desejados, precisam monitorar o sistema e determinar se a falha e os mecanismos de tolerância à falhas foram ativados, coletando dados que auxiliem no diagnóstico dos erros apresentados. Uma maneira de se reduzir essa interferência é usar técnicas híbridas, empregando ferramentas de software e de hardware.
Outro aspecto importante a ser considerado é a forma como a injeção pode ser ativada. Segundo [9], a ativação pode ocorrer por corrupção de memória, onde falhas são injetadas na área de memória alocada para o programa antes de se iniciar sua execução, por ativação espacial, a falha é injetada quando o programa atinge um certo endereço de execução ou quando faz acesso a um determinado endereço de memória ou por ativação temporal, a falha é injetada após ter decorrido um determinado período a partir do início da execução.
Considerando, ainda, o número de vezes que a injeção é ativada, as falhas podem ser classificadas em transientes, ativadas uma única vez durante a execução, intermitentes,
Dissertação de Mestrado Estratégia vara Testes de Banco de Dados Ortentados a Objetos utilizando Injeção de Falhas
ativadas repetidas vezes com base em urna distribuição estatística associada ao intervalo de tempo entre ativações ou permanentes, repetidas todas as vezes, sendo que a repetição da injeção pode ser facilitada ou dificultada pelos mecanismos de injeção e as formas de ativação,
Neste trabalho, Injeção de Falhas por Software foi a técnica utilizada,
Comparação entre as técnicas, Em [42] podemos encontrar um resumo sobre as diferenças de cada técnica em termos de vantagens e desvantagens.
A escolha método mais adequado depende de fatores, entre
acessibilidade dos componentes nos quais as falhas serão injetadas, o nível aceitável de perturbação do programa alvo, recursos oferecidos pelo ambiente de execução e objetivo dos experimentos. Isso pode explicar porque a maioria das ferramentas combina vários mecanismos, como é mostrado na próxima seção.
Apesar das desvantagens, tais como, grande impacto ínjE,tor de falhas sobre o sistema alvo, dificuldade para disparar e m<mitOJ'ar o impacto das falhas no sistema alvo ou a dificuldade para se implementar alguns tipos de falhas devido às limitações da maioria dos modelos, observadas em diversos estudos, entre eles [45], as vantagens aliadas à flexibilidade da escolha do modelo de falhas, baixa complexidade e custo, garantem ser esse método, a melhor opção para esse estudo,
II.3. Ferramentas de Injeção de Falhas.
JI,3,1, Generalidades
Como vimos nas seções anteriores, a técnica de injeção de falhas é uma valiosa abordagem para validar sistemas, em que a segurança é um requisito indispensável e para avaliar o impacto dos mecanismos de recuperação previstos, Se, eventualmente, alguma falha não for tratada, conforme a especificação, isso será detectado, podendo ser corrigido antes que o sistema entre em produção. Também vimos que para utilizar essa técnica é necessária uma ferramenta tanto para a injeção quanto para o monitoramento do sistema (ref Seção IL2),
Muitas ferramentas de Injeção de Falhas por software já foram desenvohidas, usando uma variedade de métodos para realizar a injeção, O texto seguinte apresenta algumas dessas ferramentas que serão mencionadas mais à frente nesse trabalho, Essas ferramentas foram utilizadas em trabalhos relacionados a este, validando mecanismos de recuperação em diversos gerenciadores de banco de dados, Uma relação bem mais completa das ferramentas existentes pode ser encontrada em [42].
Dissertação de A1 estrado Estratégia para Testes de Banco de Dados Orientados a Obietos utilizando Injeção de Falhas
II.3.2. Xception
Xception (Software Fault Injection and Monitoring in Processor Functional Units) [18], desenvolvida pela Universidade de Coimbra, Portugal, utiliza, para fazer injeção de falhas, algumas características especiais dos processadores mais modernos. Instruções destinadas a realizar depuração e testes de performance dos chips são utilizadas para simular falhas de hardware no sistema sob teste. Falhas são assim disparadas pela ocorrência algum evento específico, causando uma exceção de hardware. A ferramenta objetiva emular falhas de hardware, como posições de memórias presas em zero, falhas de barramento de endereço, falhas de ponteiro de instrução e outras falhas relacionadas de hardware. As falhas podem ser ativadas tanto pela ocorrência de eventos pré-selecionados como por time-outs.
O programa sob teste pode rodar a plena velocidade (não é utilizado modo traço) e não é necessário nenhum código extra para fazer a injeção de falhas e a monitorização, assim a perturbação causada é desprezível. Um problema, todmia, dessa ferramenta é sua dependência das instruções especiais de depuração e medição de desempenho dos modernos processadores tendo que ser reescrita para cada novo processador a ser utilizado. Além disso, sua disponibilidade de uso depende de um acordo com os fabricantes do chip e sendo adequada para injetar falhas de hardware é muito difícil conseguir simular falhas de software.
11.3.3. FIRE
FIRE (Fau/t Injection using a Reflective architecture) [59], criada na Universidade Estadual de Campinas, se baseia em reflexão (também conhecido como programação reflexiva) para injetar falhas em sistemas orientados a objetos. Reflexão estabelece que, além dos objetos normais de um sistema orientado a objeto, chamados objetos do nível base, existem também os meta-objetos, que podem modificar o comportamento dos objetos do nível base. Essa modificação do comportamento dos objetos do nível base, feita pelos meta-objetos, é definida e controlada por um protocolo de meta-objeto (Meta-Object Protocol - MOP) que define quais meta-objetos podem ser associados a quais objetos do nível base, e o que o meta-objeto pode observar e mudar do objeto do nível base. Modifica o valor de atributos, e retorno de métodos dos objetos do nível base. FIRE poderia injetar as conseqüências de falhas de hardware, no entanto, seu principal foco é simular as conseqüências de falhas de software.
Dissertação de Mestrado Estratéaia para Testes de Banco de Dados Orientados a Obietos utilizando Jnieção de Falhas
FIRE pode rodar o sistema sob teste a sua plena velocidade, não havendo necessidade de se usar modo traço. Embora ele utilize o método de inserção de código para implementar a injeção de falhas e a monitorização, esse código extra é parte do meta-nível, sendo assim completamente independente das funcionalidades da aplicação alvo. Esse método também apresenta grande flexibilidade com respeito ao modelo de falhas, permitindo a injeção tanto de falhas de hardware como de softv.;are, podendo trabalhar no processo de teste especificamente da aplicação e não só do sistema onde a aplicação reside. Causa alguma perturbação no sistema sob teste, uma vez que a adição de meta-objetos no sistema não modifica o código fonte, mas o código compilado será diferente do original, uma vez que a recompilação do sistema alvo terá que ser feita para adicionar os meta-obejtos. A ferramenta foi escrita em OpenC++, trabalhando, assim, somente com sistemas escritos em C++.
ComFIRM ( Communication Injection through OS Resources Modification)
[5], desenvolvida na Universidade Federal do Rio Grande do Sul, modifica o sistema operacional sobre o qual o sistema sob teste está rodando para injetar falhas. A ferramenta foi desenvolvida para ser usada com o sistema operacional Linux, que é um software "open-source", e assim os desenvolvedores podem reescrever algumas partes do Linux. Dessa forma, conseguiram colocar algumas partes da ComFIRM dentro do sistema operacional, e a ferramenta é então capaz de injetar falhas que se originam dentro do sistema operacional. A ferramenta pretende testar mecanismos de tolerância à falhas relacionadas com a comunicação dentro de um sistema distribuído, e ela o faz através da troca ou da remoção de algumas mensagens trocadas entre nós do sistema, injetando falhas de comunicação, para testar mecanismos de comunicação tolerante a falhas.
Como ComFIRM injeta falhas a partir do sistema operacional, sendo capaz de fazê-lo com baixa perturbação do sistema sob teste, que roda a plena velocidade de execução, tendo facilidade para lidar com o conteúdo de mensagens trocadas dentro do sistema distribuído. É dependente do sistema operacional Linux, podendo ser usada com sistemas alvo que rodem sobre esse sistema operacional, ficando dependente da portabilidade do Linux. Outras falhas que não a transmissão de mensagens, não são tratadas pela ferramenta.
Dissertação de 1.\iestrado Estratéqia para Testes de Banco de Dados Orientados a Objetos utilizando lniecão de Falhas
FIDe (Fault Injection Debugging) [GON 01], foi desenvolvida no PGCC da UFRGS e é baseado na depuração de programas pela sua execução até uma chamada de sistema (syscall). Considera que acessos a recursos do sistema operacional e acessos a hardware no sistema operacional GNU /Linux, se dão via chamadas do sistema operacional. Utiliza a chamada de sistema ptrace, permitindo que um processo possa ser executado de três maneiras diferentes: passo a passo, usando breakpoints ou uma execução feita até a próxima chamada sistema. A modificação do código fonte programas é necessário nas duas primeiras maneiras de execução e o acesso a esses códigos nem sempre é possível, sendo que, nesse caso, a terceira maneira é a opção indicada. O cenário de falhas é determinado pelas regras que serão utilizadas durante a execução da aplicação alvo que é armazenada no arquivo de configuração. Essas regras possuem uma sintaxe própria, sendo que a regra principal (main_rule) define qual syscall a ferramenta deve interceptar. Quando a chamada de sistema que definida na regra acontece, FIDe avalia a regra condição (rule_when) e determina se já é possível a injeção de falhas. A regra de condição pode ser baseada em tempo, fluxo ou ocorrência de determinados valores nos registradores de memória e também determina se a injeção ocorrerá na chamada ou no retorno da syscall. As ações que serão tomadas na injeção poderão ser definidas por quatro diferentes regras: rule_reg (troca valores dos registradores), rule_memo (troca conteúdo de memória), rule_param (troca conteúdo da memória que é apontado pelos registradores mais um deslocamento), rule_user (troca dados do user struct do processo). Essas regras de trocas podem se dar por incremento, decremento, atribuição e pelos operadores
aritméticos"+" e'"-".
II.3-5- TAMER
TAMER (Testing, Analysís and Measurement Environment for Robustness) [24] é uma ferramenta desenvolvida para avaliar a segurança no funcionamento de sistemas tolerantes a falhas. Três idéias básicas fazem de TAMER uma ferramenta diferente das demais existentes: uma avaliação bi-dimensional de critérios para segurança no funcionamento, injeção de falhas de interface e um esquema para particionar o sistema sob teste em subsistemas que podem ser analisados "off-line". A arquitetura de T&'V!ER é dividida em dois níveis de abstração: nível do usuário e kernel da ferramenta. A natureza interativa de TAMER permite que os avaliadores identifiquem porções do software que possam precisar de atenção para testes adicionais, reprojetos ou recodificações. Essa identificação se torna possível através de informações sobre cobertura de código e falhas que são obtidas durante o processo de teste sob o controle de TAi'VIER. TA.IviER usa injeção
Dissertação de Mestrado Estratégia para Testes de Banco de Dados Orientados a Objetos utilizando Injeção de fO.ihas
no código fonte do sistema sob teste, através da troca predeterminada de partes do código fonte, objetivando a produção de mutantes semanticamente incorretos.
Resumo.
Este capítulo apresentou uma visão geral sobre injeção de Testes por in}eçao de falhas têm sido utilizados para se testar sistemas dos quais é esperado segurança no Essa técnica tem se mostrado uma poderosa aliada na do comportamento de um sistema na presença de falhas, dando ao desenvolvedor mawr agilidade nos testes e uma visão mais segura do correto funcionamento do sistema, antes que esse seja colocado em produção.
As diferentes abordagens para injeção de falhas foram comentadas, comparando-se as vantagens e desvantagens de injeção de falhas por simulação, por hardware e por software. Pode-se concluir que, apesar das vantagens e desvantagens de cada método, a injeção de falhas por software é mais controlável e mais barata do que a injeção por hardware, e mais próxima das reais condições de execução, quando comparada com simulação.
Foram apresentados os diferentes métodos de injeção de falhas por software, tais como o uso de modo traço, de traps, de time-outs, de um processo com privilégios especiais e através da modificação do código fonte.
Muito trabalho já foi feito em injeção de falhas por softvvare, e uma certa maturidade foi atingida. Também um grande número de ferramentas de injeção de falhas por software foi construído para validar diferentes tipos de sistemas com os mais variados objetivos.
Contudo, desvantagens de se injetar falhas por software, quando comparada com injeção de falhas por hardware existem, como por exemplo, o fato desse mecanismo ser intrusivo alterando principalmente o desempenho do sistema alvo. Mas, dada às vantagens da abordagem por software, esta ainda é a melhor opção para esse trabalho.
Por último, deve-se notar que injeção de falhas por software não é uma técnica para ser utilizada, isoladamente, em um processo de teste. Maior garantia sobre a segurança no funcionamento de um sistema que está sendo desenvolvido pode ser obtida quando a injeção de falhas for trabalhada conjuntamente com outras técnicas de teste, podendo ter um papel muito importante no processo de teste de um sistema.
Dissertacão de Ai estrado Estratégia para Testes de Banco de Dados Orientados a Obietos utilizando Injeção de Falhas
Capítulo
Ferramenta de Injeção de Falhas Jaca
III.1. Generalidades.
No capítulo H vimos que, quando pretendemos utilizar injeção de falhas por software para testes de sistemas, precisamos utilizar obrigatoriamente uma ferramenta apropriada para a injeção das falhas. Simulando ou produzindo falhas, essas ferramentas executam o sistema sob teste e monitoram seu comportamento, disponibilizando para o desenvolvedor, subsídios para determinar se esse comportamento está dentro das especificações requeridas. É de extrema importância para o sucesso dos testes através da injeção de falhas, que a ferramenta utilizada seja eficiente para injetar as falhas e reportar os resultados dos testes e o comportamento do sistema em presença das mesmas'.
Jaca [49] é uma ferramenta para injeção de erros por sofuvare, cuja implementação foi escrita na linguagem Java. A ferramenta foi desenvolvida na própria universidade num trabalho de pesquisa anterior a esse[42]. Jaca é urna evolução da ferramenta FIRE (vide referência no Capítulo II.3.3) utilizada para injetar falhas em aplicações escritas em C++. Jaca foi desenvolvida para atender a diversos requisitos, tais corno: a ferramenta deveria tornar por base, para seu projeto, o sistema de padrões para injeção de erros por software, deveria ser altamente adaptável, de maneira que se a ferramenta não satisfizesse exatamente os requisitos do usuário, poderia ser reescrita para fazê-lo, deveria ser escrita em Java e utilizar reflexão computacional para fazer a injeção de erros, tal como a ferramenta FIRE [59].
Jaca monitora os sistemas para que se possa verificar se as respostas por ele produzidas estão dentro dos padrões esperados mesmo em presença de falhas. Oferece mecanismos para injetar falhas de alto nível em sistemas orientados a objetos. Isso quer dizer que não opera com rotinas em assembly ou com aspectos específicos do ambiente computacional, onde a ferramenta está sendo executada. Para injetar falhas de alto nível, utiliza reflexão computacional permitindo uma grande facilidade de adaptação, atendendo à especificação de qualquer sistema Java com um mínimo de reescrita.
Utiliza um protocolo de meta-objetos, o Javassist [12], encarregado de implementar a reflexão dentro da Jaca, para permitir que a injeção de erros seja relativamente simples, tendo como vantagem o fato de não necessitar do código fonte do sistema sob teste, uma
Dissertação de ;'\llestrado Estratégia para Testes de Banco de Dados Orientados a Obietos utihzando lnieção de Falhas
vez que no Javassist a reflexão é introduzida no bytecode, proporcionando essa independência. Outro fator relevante é a portabilidade
da ferramenta que pode rodar em qualquer plataforma que possa executar a Máquina Virtual Padrão do Java (JVM padrão).
Jaca pode afetar a atribuição de valores a atributos, parâmetros de chamadas de métodos e valores de retorno métodos, utilizando para isso dois arquivos, um que especifica as falhas a serem injetadas e outro as classes a serem monitoradas, cuja formatação será descrita adiante. Jaca foi projetada para injetar valores inteiros, reais, booleanos, caracteres e strings, mas verificamos que na versão atual a ferramenta está injetando apenas valores inteiros e reais.
A seguir, iremos descrever a arquitetura da ferramenta Jaca para um melhor entendimento de seus componentes, interfaces e associações.
III.2.Arquitetura da Ferramenta
A arquitetura da ferramenta que estamos utilizando neste trabalho e cujo esquema é apresentado na figura 1, apresenta cinco componentes:
• Controlador- que coordena os demais componentes. • Injetor- que injeta as falhas no sistema sob teste.
• Monitor - que coleta informações do comportamento do sistema sob teste quando em presença de falhas.
• Ativador - que ativa o sistema que irá exercitar as falhas injetadas.
• Interface_USR- que permite ao usuário especificar os experimentos, acompanhar seu progresso e obter os resultados.
No diagrama abaixo, podemos verificar que a comunicação entre os componentes é feita pelo Controlador. Essa decisão de projeto pode ter adicionado uma certa complexidade ao Controlador, mas permitiu que tanto o Injetor quanto o Monitor fossem simplificados. Como esses componentes podem residir no sistema sob teste, é interessante que eles sejam o mais simples possível para que a intrusão da ferramenta seja minimizada.
O Injetor, o Monitor e o Ativador mantêm uma comunicação direta com o sistema sob teste, podendo ser criadas várias instâncias tanto do Injetor quanto do Monitor para que diferentes partes do sistema possam ser injetadas e monitoradas durante um experimento.
i Dado que a ferramenta injeta falhas de alto níveL que simulam conseqüência de falhas de software,
Dissertação de Mestrado Estratégia para Testes de Banco de Dados Orientados a Objetos utilizando Injeção de Falhas
A arquitetura possui ainda dois repositórios, o Ger_Falhas que armazena as falhas a serem injetadas e o Ger_D_Monit que armazena os dados coletados pelo Monitor durante o período de injeção.
O Injetor compreende três sub componentes: o gerenciador de injeção, o injetor lógico e o físico. O gerenciador de injeção controla o processo de injeção instanciando o injetor lógico de acordo com as falhas especificadas em Ger_Falhas e ativando-o quando o momento de injeção (número do acesso ao método ou atributo) é atingido. Vários injetores lógicos podem ser instanciados para o caso de um ambiente multi-threaded. O injetor lógico fica assim ligado à injeção de um erro específico, mas não interage diretamente com a aplicação, o que é feito através do injetor físico que realmente irá injetar as falhas especificadas. A injeção será possível através das operações disponibilizadas na interface do injetor físico, que permitem a interação com o sistema sob teste e seu ambiente.
INTERFACE_USR I Interface
IGerFalha IControl IGerMonit
IMonit llnjet
lAti v
INJETOR ATIVADOR
Fíg. 1: Diagrama da Arquitetura da Jaca [42]
O Monitor é bastante similar ao Injetor. Tem-se um sensor físico, que irá interceptar cada escrita de um atributo ou chamada de método do objeto do nível de aplicação, registrando os valores envolvidos. Os valores de escrita em atributo e retorno de chamada de método são passados para os respectivos sensores, que empacotam os dados e os repassam ao Controlador que os armazena em Ger_D _Monit.
Para um melhor entendimento da ferramenta foram descritos, com um pouco mais de detalhes, os componentes Injetor e Monitor. Tanto um quanto outro utilizam a reflexão
Dissertação de Mestrado Estratégia para Testes de Banco de Dados Orientados a Objetos utilizando Injeção de Falhas
para executar suas tarefas (injetar falhas ou monitorar a injeção), o que será discutido na próxima seção. Detalhes mais completos sobre a arquitetura da Jaca podem ser obtidos em [42], [44] e [49].
.!..!..L •• ,).
Reflexão Computacional na
A arquitetura da Jaca foi implementada utilizando reflexão computacional. Reflexão é
obtida através da subdivisão da arquitetura do sistema em pelo menos dois nível base (ou funcional) e meta (ou não funcional). No nível base, são implementadas todas as funcionalidades da aplicação e no meta nível são feitos o monitoramento e a manipulação da estrutura ou comportamento do nível base [49].
A ferramenta de injeção de erros por software tem muitas vantagens na utilização da reflexão, uma vez que a reflexão é relativamente fácil de ser utilizada e quando utilizada, o
usuário precisa informações detalhadas advindas hardware e sistema
operacional. Por outro lado, a ferramenta é limitada pelas funcionalidades que são disponibilizadas pela ferramenta que implementa essa reflexão.
Quando a Jaca foi implementada, o Javassist [12] foi escolhido como ferramenta de reflexão devido à conformidade dessa ferramenta com os requisitos da Jaca. Requisitos como portabilidade (Javassist não modifica a JVM padrão), introspecção nas classes (Javassist provê métodos que alteram a definição das classes), independência de código fonte (Javassist manipula o bytecode) e facilidade de uso foram possíveis com a utilização do Javassist.
Como já citado anteriormente, tanto o Injetor quanto o Monitor utilizam a reflexão. Quando um objeto do nível base que deverá ser injetado é instanciado, o Javassist automaticamente associa-o com um objeto da classe Injetor Físico, de acordo com o objeto onde a falha vai ser injetada. O meta-objeto irá se comunicar com gerenciador de injeção, e se associará à lista de Injetores. Esse meta-objeto (injetor físico) possui métodos para interceptar cada leitura ou escrita nos atributos do objeto e, também, para cada invocação de um método do objeto no nível da aplicação. Quando ocorre um desses eventos, a operação é interceptada pelo injetor físico; o meta-objeto passa os dados para o Injetor correspondente (injeção de atributos, parâmetros ou retorno de métodos), que irão proceder a injeção de erros. Por exemplo, se ocorre uma leitura do valor de um atributo do objeto do nível de aplicação, o meta-objeto intercepta essa leitura, repassa o valor do atributo e uma indicação de que se estava fazendo uma leitura dele, para o Injetor de Atributo associado. Se houver uma programação para injetar uma falha precisamente na leitura desse atributo, ele irá tomar o valor que foi lido, executar a operação indicada na
