especificação e validação de benchmarks confiabilidade ... · chmarks de confiabilidade é...

10
Resumo— A avaliação padronizada (benchmarking) da confi- abilidade de componentes e sistemas informáticos tem sido alvo de intensa investigação nos últimos anos. Resultados recentes leva- ram à proposta de novas benchmarks para sistemas de bases de dados. No entanto, não existe ainda uma metodologia clara para a definição de tais benchmarks. Adicionalmente, a validação das benchmarks tem sido largamente ignorada. Este último aspecto é extremamente importante, uma vez que o objectivo final das ben- chmarks de confiabilidade é proporcionar meios eficientes de comparação de sistemas/componentes. Sem uma adequada valida- ção da benchmark, as conclusões obtidas podem ser erróneas. Este artigo propõe um conjunto de linhas orientadoras para a defini- ção e validação de benchmarks de confiabilidade em sistemas OLTP (On-Line Transaction Processing) centrados em sistemas de bases de dados. O forte relacionamento existente entre a defi- nição e a validação de uma benchmark é também claramente evi- denciado e discutido no artigo. Palavras-Chave– Bases de dados, Benchmarking, Confiabili- dade, Sistemas transaccionais. I. INTRODUÇÃO objectivo das benchmarks de confiabilidade é o de pro- porcionar formas padronizadas de avaliação tanto da con- fiabilidade como do desempenho de sistemas e componentes informáticos. Comparativamente às clássicas benchmarks de desempenho, tais como as do SPEC (www.spec.org) e do TPC (www.tpc.org), que consistem essencialmente numa workload e num conjunto de medidas de desempenho, uma benchmark para avaliação de confiabilidade adiciona dois novos elemen- tos: 1) medidas relacionadas com confiabilidade (caracteri- zam a confiabilidade do sistema), e 2) uma faultload (conjunto de falhas que reproduzem falhas observadas em sistemas re- ais). Recentemente foram propostas várias benchmarks de confi- abilidade cobrindo, diversos domínios, tais como sistemas de bases de dados [1, 2], servidores web [3], sistemas operativos [4, 5, 6] e hardware [7, 8]. No entanto, não foi ainda proposta Este trabalho foi financiado, em parte, pelo Governo Português/União Eu- ropeia através da unidade de I&D 326/94 (CISUC) e pelo projecto DBench, IST 2000 - 25425 DBENCH, financiado pela União Europeia. M. Vieira, ISEC/CISUC – Instituto Superior de Engenharia de Coimbra, 3030 Coimbra, Portugal (e-mail: [email protected]) J. Durães, ISEC/CISUC – Instituto Superior de Engenharia de Coimbra, 3030 Coimbra, Portugal (e-mail: [email protected]) H. Madeira, DEI/CISUC – Universidade de Coimbra, 3030 Coimbra, Por- tugal (e-mail: [email protected]) nenhuma metodologia para a definição e validação de novas benchmarks de confiabilidade. Saber até que ponto se pode confiar nos resultados e uma benchmark é, muito provavelmente, o aspecto mais importante no desenvolvimento de novas benchmarks, uma vez que o seu objectivo final é comparar diferentes sistemas/componentes. Tal significa que sem uma validação adequada da benchmark, as conclusões obtidas podem ser erróneas. Neste artigo é proposta uma abordagem para a validação de benchmarks de confiabilidade em sistemas transaccionais típi- cos (sistemas assentes num sistema de gestão de bases de da- dos (SGBD)) e discutido um conjunto de linhas orientadoras para a definição de novas benchmarks de confiabilidade neste domínio de aplicação. O estreito relacionamento existente en- tre a definição da benchmark e a sua validação é igualmente apresentado e discutido. O método de validação consiste em verificar experimentalmente se os componentes principais da benchmark obedecem a um conjunto de propriedades chave: representatividade (a benchmark tem que representar sistemas reais), portabilidade (a benchmark deve ser aplicável a dife- rentes sistemas), repetibilidade (a benchmark deve produzir resultados semelhantes quando executada mais que uma vez no mesmo ambiente), escalabilidade (a benchmark deverá ser capaz de avaliar sistemas/componentes de diversas dimen- sões), não-intrusividade (a execução da benchmark deve exigir um mínimo de alterações no sistema alvo ou, idealmente, ne- nhuma alteração), e simplicidade de uso (a benchmark deve ser fácil de implementar e utilizar). A abordagem aqui propos- ta é ilustrada através de um exemplo concreto de validação de uma benchmark de confiabilidade para ambientes OLTP (a benchmark DBench-OLTP [1]). A estrutura do artigo é a seguinte: na próxima secção são apresentadas e discutidas as linhas gerais para a definição de benchmarks de confiabilidade em sistemas OLTP. A Secção III apresenta a proposta de abordagem para validação de ben- chmarks de confiabilidade. A Secção IV apresenta a ben- chmark DBench-OLTP e os sistemas usados nas experiências apresentadas. Na secção V são apresentados e discutidos os resultados experimentais. A secção VI conclui o artigo. II. DEFINIÇÃO DE BENCHMARKS DE CONFIABILIDADE EM SISTEMAS OLTP Um ambiente OLTP típico consiste num conjunto de utili- zadores que submetem as suas transacções através de um ter- minal ligado a um servidor usando uma rede local ou a Web. Especificação e Validação de Benchmarks de Confiabilidade para Sistemas Transaccionais Marco Vieira, João Durães e Henrique Madeira O 72 IEEE LATIN AMERICA TRANSACTIONS, VOL. 3, NO. 1, MARCH 2005

Upload: trantruc

Post on 26-Jan-2019

214 views

Category:

Documents


0 download

TRANSCRIPT

Resumo— A avaliação padronizada (benchmarking) da confi-

abilidade de componentes e sistemas informáticos tem sido alvo de intensa investigação nos últimos anos. Resultados recentes leva-ram à proposta de novas benchmarks para sistemas de bases de dados. No entanto, não existe ainda uma metodologia clara para a definição de tais benchmarks. Adicionalmente, a validação das benchmarks tem sido largamente ignorada. Este último aspecto é extremamente importante, uma vez que o objectivo final das ben-chmarks de confiabilidade é proporcionar meios eficientes de comparação de sistemas/componentes. Sem uma adequada valida-ção da benchmark, as conclusões obtidas podem ser erróneas. Este artigo propõe um conjunto de linhas orientadoras para a defini-ção e validação de benchmarks de confiabilidade em sistemas OLTP (On-Line Transaction Processing) centrados em sistemas de bases de dados. O forte relacionamento existente entre a defi-nição e a validação de uma benchmark é também claramente evi-denciado e discutido no artigo.

Palavras-Chave– Bases de dados, Benchmarking, Confiabili-dade, Sistemas transaccionais.

I. INTRODUÇÃO

objectivo das benchmarks de confiabilidade é o de pro-porcionar formas padronizadas de avaliação tanto da con-

fiabilidade como do desempenho de sistemas e componentes informáticos. Comparativamente às clássicas benchmarks de desempenho, tais como as do SPEC (www.spec.org) e do TPC (www.tpc.org), que consistem essencialmente numa workloade num conjunto de medidas de desempenho, uma benchmarkpara avaliação de confiabilidade adiciona dois novos elemen-tos: 1) medidas relacionadas com confiabilidade (caracteri-zam a confiabilidade do sistema), e 2) uma faultload (conjunto de falhas que reproduzem falhas observadas em sistemas re-ais).

Recentemente foram propostas várias benchmarks de confi-abilidade cobrindo, diversos domínios, tais como sistemas de bases de dados [1, 2], servidores web [3], sistemas operativos [4, 5, 6] e hardware [7, 8]. No entanto, não foi ainda proposta

Este trabalho foi financiado, em parte, pelo Governo Português/União Eu-

ropeia através da unidade de I&D 326/94 (CISUC) e pelo projecto DBench, IST 2000 - 25425 DBENCH, financiado pela União Europeia.

M. Vieira, ISEC/CISUC – Instituto Superior de Engenharia de Coimbra, 3030 Coimbra, Portugal (e-mail: [email protected])

J. Durães, ISEC/CISUC – Instituto Superior de Engenharia de Coimbra, 3030 Coimbra, Portugal (e-mail: [email protected])

H. Madeira, DEI/CISUC – Universidade de Coimbra, 3030 Coimbra, Por-tugal (e-mail: [email protected])

nenhuma metodologia para a definição e validação de novas benchmarks de confiabilidade.

Saber até que ponto se pode confiar nos resultados e uma benchmark é, muito provavelmente, o aspecto mais importante no desenvolvimento de novas benchmarks, uma vez que o seu objectivo final é comparar diferentes sistemas/componentes. Tal significa que sem uma validação adequada da benchmark,as conclusões obtidas podem ser erróneas.

Neste artigo é proposta uma abordagem para a validação de benchmarks de confiabilidade em sistemas transaccionais típi-cos (sistemas assentes num sistema de gestão de bases de da-dos (SGBD)) e discutido um conjunto de linhas orientadoras para a definição de novas benchmarks de confiabilidade neste domínio de aplicação. O estreito relacionamento existente en-tre a definição da benchmark e a sua validação é igualmente apresentado e discutido. O método de validação consiste em verificar experimentalmente se os componentes principais da benchmark obedecem a um conjunto de propriedades chave: representatividade (a benchmark tem que representar sistemas reais), portabilidade (a benchmark deve ser aplicável a dife-rentes sistemas), repetibilidade (a benchmark deve produzir resultados semelhantes quando executada mais que uma vez no mesmo ambiente), escalabilidade (a benchmark deverá ser capaz de avaliar sistemas/componentes de diversas dimen-sões), não-intrusividade (a execução da benchmark deve exigir um mínimo de alterações no sistema alvo ou, idealmente, ne-nhuma alteração), e simplicidade de uso (a benchmark deve ser fácil de implementar e utilizar). A abordagem aqui propos-ta é ilustrada através de um exemplo concreto de validação de uma benchmark de confiabilidade para ambientes OLTP (a benchmark DBench-OLTP [1]).

A estrutura do artigo é a seguinte: na próxima secção são apresentadas e discutidas as linhas gerais para a definição de benchmarks de confiabilidade em sistemas OLTP. A Secção III apresenta a proposta de abordagem para validação de ben-chmarks de confiabilidade. A Secção IV apresenta a ben-chmark DBench-OLTP e os sistemas usados nas experiências apresentadas. Na secção V são apresentados e discutidos os resultados experimentais. A secção VI conclui o artigo.

II. DEFINIÇÃO DE BENCHMARKS DE CONFIABILIDADE EM SISTEMAS OLTP

Um ambiente OLTP típico consiste num conjunto de utili-zadores que submetem as suas transacções através de um ter-minal ligado a um servidor usando uma rede local ou a Web.

Especificação e Validação de Benchmarks de Confiabilidade para Sistemas Transaccionais

Marco Vieira, João Durães e Henrique Madeira

O

72 IEEE LATIN AMERICA TRANSACTIONS, VOL. 3, NO. 1, MARCH 2005

De uma forma simplificada, o servidor é composto por três componentes principais: a plataforma de hardware (incluindo o subsistema de armazenamento), o sistema operativo e o motor transaccional. A maior parte dos ambientes transaccionais usa um sistema de gestão de bases de dados (SGBD) como motor transaccional, o que faz deste o principal componente de qual-quer sistema OLTP, assegurando não só as propriedades tran-saccionais mas também os mecanismos de recuperação.

A confiabilidade é um conceito que integra vários atributos [9, 10]: disponibilidade (prontidão para prestação de um servi-ço), fiabilidade (prestação de um serviço correcto), segurança (ausência de consequências catastróficas para o ambiente e respectivos utilizadores), confidencialidade (ausência de aces-sos não autorizados), integridade (ausência de alterações in-correctas no estado do sistema) e facilidade de manutenção (capacidade para suportar reparações e modificações).

Uma benchmark de confiabilidade consiste numa especifi-cação de um procedimento standard para avaliar e comparar medidas relacionadas com a confiabilidade de sistemas ou componentes. O sistema/componente caracterizado pela ben-chmark é denominado SUB (System Under Benchmark).

Os principais componentes da DBench-OLTP são: • Medidas: caracterizam o desempenho e confiabilidade

do sistema em avaliação. • Workload: representa o trabalho que o sistema deve rea-

lizar durante a execução da benchmark.• Faultload: representa um conjunto de falhas e condições

excepcionais, que emulam falhas reais em sistemas tran-saccionais em utilização efectiva.

• Procedimentos e regras: descrição dos procedimentos e regras que devem ser seguidos durante a implementação e execução da benchmark.

• Ambiente experimental: descreve a bancada experi-mental necessária para executar a benchmark.

Neste trabalho propõe-se os seguintes passos genéricos para a especificação de uma benchmark de confiabilidade:

1) O primeiro passo consiste na identificação do domínio de aplicação. A divisão em domínios de aplicação é necessária de forma a lidar com a grande diversidade de sistemas e aplicações existentes, e assim tornar possível a tomada de opções durante a definição dos componen-tes da benchmark (esta é também a abordagem seguida nas benchmarks para avaliação do desempenho). De facto, a maior parte dos componentes depende do do-mínio de aplicação em causa. Por exemplo, as medidas, as falhas (externas) mais comuns e a workload (só para referir alguns exemplos) são extremamente dependentes do domínio de aplicação da benchmark. Este artigo foca essencialmente sistemas transaccionais típicos que usam um SGBD como motor transaccional.

2) O segundo passo é a caracterização do SUB em ter-mos de funcionalidades e características (incluindo ca-racterísticas de confiabilidade que se espera encontrar no conjunto de potenciais sistemas alvo). Por exemplo, para aplicações transaccionais pode ser assumido que o SUB é qualquer sistema capaz de executar transacções

de acordo com as propriedades transaccionais típicas (atomicidade, consistência, isolamento, e durabilidade, também conhecidas por propriedades ACID).

3) O terceiro passo consiste na definição das medidas.Uma vez que a especificação dos restantes componen-tes da benchmark pode depender das medidas a obter, este é o primeiro componente a ser definido. Para dife-rentes domínios de aplicação podem ser necessárias medidas diferentes.

4) A definição dos restantes componentes (workload,faultload, ambiente experimental e procedimentos e re-gras) é realizada no último passo. Apesar da especifica-ção destes componentes não ser sempre dependente das medidas, existem normalmente algumas dependências. Por exemplo, a workload e a faultload estão frequen-temente relacionadas com as medidas de interesse.

As secções que se seguem discutem mais em detalhe os as-pectos a ter em conta em cada passo da definição de uma ben-chmark para o domínio de aplicação de sistemas OLTP:

A. Medidas Numa benchmark de confiabilidade podem ser considera-

das duas classes de medidas: • Medidas condicionais: medidas que caracterizam o sis-

tema de uma forma relativa (i.e., medidas que estão di-rectamente relacionadas com as condições em que a benchmark é executada) e cujo objectivo principal é a comparação de diferentes sistemas.

• Medidas incondicionais sobre atributos de confiabi-lidade: medidas que caracterizam a confiabilidade do sistema de uma forma global. Estas medidas têm em con-sideração a ocorrência de vários eventos que podem afec-tar o comportamento do sistema em utilização real, e in-cluem: disponibilidade, fiabilidade, segurança, confiden-cialidade, integridade e facilidade de manutenção [9, 10].

Tal como representado na Fig. 1, as medidas condicionais são directamente obtidas através da execução de experiências. As medidas incondicionais sobre atributos de confiabilidade são calculadas usando técnicas de modelação e dados externos, como por exemplo taxas de ocorrência de falhas, tempo médio entre avarias (MTBF), etc. De salientar que os modelos de sistemas complexos podem ser muito difíceis de definir e os dados externos árduos de obter.

Fig. 1. Medidas de uma benchmark de confiabilidade em sistemas OLTP.

Neste trabalho propõe-se a utilização somente de medidas condicionais, seguindo a filosofia tradicionalmente usada em benchmarking, que é baseada numa abordagem puramente experimental. Estas medidas, directamente relacionadas com as condições em que a benchmark é executada, podem ser

Workload

Modelos

Medições

Medidas incondicionais sobre atributos de

confiabilidade

Medidascondicionais

Faultload

Dados externos (taxas de ocorrência de falhas, MTBF, etc.)

System under

Benchmarking(SUB)

VIEIRA et al.: HOW TO SPECIFY AND VALIDATE DEPENDABILITY 73

usadas apenas para a comparação e optimização de sistemas e componentes (de uma forma similar ao que acontece com as benchmarks de desempenho, onde as medidas não fornecem uma caracterização absoluta do desempenho do sistema, não podendo assim ser usadas para planear a capacidade ou para prever o desempenho efectivo do sistema quando usado na realidade). Deste modo, as medidas de uma benchmark de confiabilidade devem ser entendidas como resultados úteis somente para caracterizar a confiabilidade de sistemas de uma forma relativa (e.g., para comparar diferentes alternativas).

As medidas de uma benchmark de confiabilidade em ambi-entes OLTP devem ser seleccionadas de modo a satisfazer as seguintes características/objectivos:

− Devem ser baseadas no serviço prestado pelo sistema durante a execução da benchmark e devem ser indepen-dentes da estrutura interna do sistema (a escolha de me-didas dependentes da estrutura detalhada do sistema tor-naria difícil, ou até impossível, a portabilidade da ben-chmark e, consequentemente, a comparação de diferen-tes sistemas). As medidas típicas de confiabilidade de-vem caracterizar o impacto das falhas no serviço presta-do pelo sistema.

− Focar o ponto de vista dos utilizadores finais do sistema. − Permitir a caracterização tanto das características de

confiabilidade como de desempenho (em sistemas OLTP, as medidas de desempenho devem também fazer parte do conjunto de medidas de uma benchmark de confiabilidade).

− Devem ser fáceis de obter e de perceber por parte dos utilizadores e administradores de bases de dados.

− As medidas não devem ser extrapoladas ou inferidas, devendo ser directamente calculadas com base na in-formação recolhida durante a execução da benchmark.

B. Faultload A faultload representa um conjunto de falhas e condições

excepcionais que emulam falhas reais experimentadas por sis-temas transaccionais em utilização efectiva. De todos os com-ponentes necessários para definir uma benchmark de confiabi-lidade em sistemas transaccionais (medidas, ambiente experi-mental, procedimentos e regras, workload e faultload), a faul-tload é declaradamente o mais problemático devido à natureza complexa das falhas.

Uma faultload pode ser baseada em três classes de falhas: • Falhas de operador: as falhas de operador em sistemas

OLTP representam erros por parte do administrador de bases de dados [11, 12]. A elevada complexidade das ta-refas de administração e a necessidade de uma optimiza-ção e administração diária, explicam claramente porque é que as falhas de operador (i.e., tarefas de administração incorrectas) são prevalecentes neste tipo de sistemas.

• Falhas de software: as falhas de software (i.e., defeitos de programação ou bugs) são reconhecidas como uma das mais importantes causas de problemas em qualquer tipo de sistemas [13, 14], e, dada a elevada complexida-de do software desenvolvido actualmente, a sua impor-

tância tende a aumentar. Resultados recentes mostram que é possível emular falhas de software de acordo com os tipos de falhas que ocorrem mais frequentemente em sistemas reais [15, 16].

• Falhas de hardware: as falhas de hardware tradicio-nais, tais como bit flips e stuck-at, não são normalmente consideradas importantes em sistemas OLTP típicos (apesar da alta densidade das novas tecnologias de cir-cuitos integrados poder levar ao aumento de falhas tran-sitórias). Por outro lado, as avarias ao nível dos compo-nentes de hardware, tais como avarias de discos e de componentes de rede, são bastante frequentes (a maior parte dos SGBD existentes possuem mecanismos de re-cuperação especificamente desenvolvidos para recuperar deste tipo de avarias).

Neste trabalho, propõe-se que a faultload seja definida sem ter em consideração possíveis taxas de ocorrência de falhas, uma vez que estas não se encontram normalmente disponíveis para sistemas complexos. No entanto, tal como proposto na Subsecção II.A, se esses dados externos existirem, é possível estimar medidas incondicionais dos atributos de confiabilidade através da utilização de modelos. Neste caso, os resultados obtidos através da execução das experiências são também usa-dos como entradas do modelo.

C. Workload A definição da workload para uma benchmark de confiabi-

lidade em sistemas OLTP está consideravelmente simplificada pela existência das workloads das benchmarks para a avalia-ção do desempenho em sistemas de bases de dados do TPC (www.tpc.org). Obviamente, estas workloads já bem estabele-cidas representam uma escolha natural para uma benchmark de confiabilidade.

D. Procedimentos e Regras Os procedimentos e regras que devem ser seguidos durante

a execução da benchmark devem ser claramente definidos durante a sua especificação. Apesar de estes procedimentos e regras dependerem de cada benchmark, os pontos seguintes apresentam algumas linhas orientadoras sobre aspectos genéri-cos necessários na maioria dos casos:

− Procedimentos standard para “transformar” a especifica-ção numa aplicação real que será executada sobre os sis-temas em teste (válido apenas para as benchmarks for-necidas sobre a forma de um documento).

− Condições uniformes para construir o ambiente experi-mental, executar as tarefas de inicialização que possam ser necessárias e executar a benchmark de acordo com a especificação.

− Regras relacionadas com a recolha dos resultados. Estas regras podem incluir, por exemplo, nível de instrumen-tação do sistema, grau máximo de interferência permiti-do (e.g., no impacto no desempenho), precisão para as medidas temporais, etc.

− Regras para a produção dos resultados finais a partir dos dados recolhidos durante a execução das experiências,

74 IEEE LATIN AMERICA TRANSACTIONS, VOL. 3, NO. 1, MARCH 2005

tais como fórmulas de cálculo, formas de lidar com in-certeza, erros e intervalos de confiança, etc.

− Regras de escalabilidade para adaptar a benchmark a sistemas de tamanhos distintos. Estas regras devem de-finir a forma como deve ser alterada a carga de trabalho que o sistema deve executar. À primeira vista, as regras de escalabilidade estão apenas relacionadas como o de-sempenho do sistema e afectam somente a workload. No entanto, uma das tarefas durante a especificação da ben-chmark, passa por investigar a necessidade de definir regras de escalabilidade para os restantes componentes (designadamente para a faultload).

− Requisitos de divulgação de informação necessários para que terceiros possam interpretar e reproduzir os re-sultados da execução da benchmark.

− Regras para evitar a produção de resultados optimistas ou resultados que dêem resultados erróneos.

E. Ambiente Experimental O ambiente experimental descreve a plataforma necessária

para executar a benchmark, sendo composto pelos seguintes elementos principais (ver também Fig. 2):

• BT (Benchmark Target): representa o sistema ou com-ponente que o utilizador da benchmark pretende caracte-rizar. Num sistema OLTP, o BT é normalmente o motor transaccional.

• SUB (System Under Benchmarking): na prática, para caracterizar o BT é necessário considerar um sistema mais abrangente denominado SUB. Do ponto de vista da benchmark, o SUB representa o sistema onde as medi-das se aplicam e fornece o suporte necessário para a execução do BT. Num sistema OLTP, o SUB inclui to-dos os componentes necessários para executar o motor transaccional (e.g., sistema operativo, hardware, etc.).

• BMS (Benchmark Management System): sistema res-ponsável pelo controlo das experiências. O objectivo deste componente é tornar a execução da benchmark um processo completamente automático. As tarefas associa-das ao BMS devem ser claramente definidas durante a especificação da benchmark.

III. VALIDAÇÃO DE BENCHMARKS DE CONFIABILIDADE EM SISTEMAS OLTP

Para ser útil, uma benchmark deve ser representativa, por-tável, produzir resultados reprodutíveis, escalável, não-intrusiva e simples de utilizar [17]. Deste modo, a validação de uma benchmark de confiabilidade em sistemas transaccionais consiste em verificar experimentalmente se os seus principais componentes satisfazem estas propriedades. As subsecções seguintes apresentem algumas linhas orientadoras sobre como validar cada propriedade.

A. RepresentatividadeDe modo a fornecer resultados relevantes, uma benchmark

deve ser representativa de sistemas reais dentro do seu domí-nio de aplicação.

A representatividade é difícil de verificar e não pode ser va-lidada por experimentação. No entanto, esta propriedade deve ser um dos pontos mais importantes a ter em conta na especifi-cação da benchmark. Nas benchmarks de confiabilidade a representatividade é influenciada pelas características das me-didas, da workload, e da faultload.

Fig. 2. Ambiente experimental de uma benchmark de confiabilidade em sistemas OLTP.

As medidas estão fortemente relacionadas com o domínio de aplicação da benchmark e devem caracterizar os sistemas alvo de uma forma adequada e útil. Ou seja, as medidas devem reflectir de uma forma realista as características de confiabili-dade do SUB e simultaneamente permitir a comparação de diferentes sistema dentro do domínio de aplicação em causa.

A representatividade da workload é essencial para verificar se o perfil das transacções consideradas inclui aquelas que simulam (de uma forma realística) o trabalho submetido em sistemas OLTP reais.

Relativamente à faultload, deverá ser verificado se as falhas abrangidas representam de facto as falhas que existem nos sistemas reais. Para esta validação devem ser utilizados dados relativos a falhas descobertas em sistemas em operação. No entanto, esta tarefa é dificultada pelo facto da informação rela-tiva a falhas encontradas em sistemas em operação não ser, normalmente, de domínio público. Dependendo da classe de falha (falhas de operador, falhas de hardware, ou falhas de software), os trabalhos previamente publicados na área de con-fiabilidade são provavelmente a melhor fonte de informação para obtenção de uma faultload representativa.

B. PortabilidadeUma benchmark deve ser portável de modo a permitir a

comparação de diferentes sistemas ou componentes no seu domínio de aplicação.

A melhor forma de avaliar a portabilidade consiste em im-plementar e executar a benchmark num conjunto de ambientes representativos. Através da avaliação de sistemas que se en-contram na fronteira do domínio de aplicação torna-se possível avaliar a aplicabilidade da benchmark em sistemas muito dife-rentes.

Na validação de uma benchmark de confiabilidade para sis-temas OLTP, devem ser consideradas diversas famílias de motores transaccionais (e.g., Oracle, PostgreSQL, Sybase, etc.) assim como diversas famílias de sistemas operativos (e.g., Windows, Linux, HP-UX, etc.), uma vez que algumas classes de falhas podem depender do motor transaccional (e.g., falhas de operador) e outras do sistema operativo em causa (e.g.,falhas de software).

System Under Benchmarking

(SUB)

Benchmark Management

System(BMS) Benchmark

Target (BT)

Workload

Faultload

Dados Controlo

VIEIRA et al.: HOW TO SPECIFY AND VALIDATE DEPENDABILITY 75

C. RepetibilidadeDe modo a fornecer resultados credíveis, uma benchmark

deve reportar resultados similares quando executada mais do que uma vez no mesmo ambiente.

A reprodutibilidade de resultados deve ser encarada de uma forma estatística, uma vez que é virtualmente impossível re-produzir de uma forma exacta as mesmas condições, em ter-mos do estado do sistema alvo, durante a execução da ben-chmark. Na prática, os pequenos desvios nas medidas em exe-cuções sucessivas constituem uma situação normal e reflectem a natureza assíncrona da submissão de transacções num siste-ma OLTP (este aspecto é bastante conhecido nas benchmarksde desempenho).

A repetibilidade da benchmark pode ser verificada execu-tando a benchmark repetidamente no mesmo sistema. Os resul-tados são analisados e as variações são identificadas. A varia-ção máxima representa o intervalo no qual os sistemas são considerados como tendo resultados semelhantes. Note-se que deve ser considerado um conjunto de sistemas representativos, uma vez que a variação dos resultados pode depender dos sis-temas em questão (i.e., em alguns sistemas a variação poderá ser maior que noutros).

O factor humano é um aspecto importante na questão da re-petibilidade dos resultados. Se possível, durante o processo de validação, a benchmark deverá ser implementada e executada por equipas diferentes (mas usando o mesmo sistema alvo), de forma a verificar se os resultados obtidos são semelhantes e confirmar que a especificação da benchmark pode ser imple-mentada por diferentes equipas sem que os resultados obtidos por cada equipa para o mesmo sistema sejam diferentes.

D. EscalabilidadeUma benchmark deve ser capaz de avaliar sistemas de esca-

las diferentes e (quando possível) permitir a comparação de sistemas de tamanhos distintos. A melhor forma de avaliar a escalabilidade é através da implementação e utilização da ben-chmark em sistemas de dimensões muito distintas.

A workload deve possuir um factor de escalabilidade que permita o redimensionamento dos dados e do número de tran-sacções submetidas de acordo com a dimensão do SUB.

No que diz respeito à faultload, o número de falhas pode depender da dimensão do SUB (por exemplo, um sistema OLTP com um grande número de discos poderá ser levar à existência de mais falhas de disco na faultload). No entanto, é necessário verificar se em sistemas de dimensão muito grande, a faultload não se torna impraticável. Note-se que o número de falhas da faultload pode influenciar o tempo necessário para a execução da benchmark.

Por último, um aspecto muito importante a verificar diz respeito à capacidade da benchmark para comparar sistemas de dimensões diferentes. Por outras palavras, a benchmarkdeverá permitir não só a avaliação de sistemas de dimensões diversas, mas também permitir a comparação entre sistemas de diferentes dimensões.

E. Não-intrusividadeUma benchmark deve requerer poucas (ou nenhumas) alte-

rações no sistema alvo. Uma benchmark é intrusiva quando, para a sua execução, é necessário realizar modificações no sistema em teste. Essas modificações são normalmente dispen-diosas e reduzem a portabilidade da benchmark.

A intrusividade poderá ser avaliada durante a fase de im-plementação. Se a implementação da workload ou da faultloadintroduzir alterações no SUB (alterações que podem ser estru-turais ou de comportamento) significa que a benchmark é in-trusiva. Evidentemente que se a benchmark for intrusiva, as medidas obtidas deixam de descrever o SUB. A propriedade de não-intrusividade é normalmente fácil de verificar.

F. Simplicicade de UtilizaçãoUma benchmark deve ser fácil de implementar e executar,

estando a sua utilidade fortemente relacionada com a sua sim-plicidade (os utilizadores tendem a ignorar benchmarks de difícil implementação ou execução). Para além disso, a execu-ção de uma benchmark deve ser pouco dispendiosa, comple-tamente automática e não deve consumir demasiado tempo. Durante a implementação e execução da benchmark é possível avaliar a sua simplicidade de utilização.

Outro ponto importante relacionado com a simplicidade de utilização da benchmark consiste em verificar se a especifica-ção é clara e completa, e em assegurar que essa especificação cobre todas as questões relevantes que possam surgir durante implementação da benchmark.

Por último, o tempo necessário para implementar e executar a benchmark deve também ser avaliado. Idealmente a execu-ção não deverá ocupar mais algumas horas por sistema. No entanto, devido à complexidade dos sistemas transaccionais, um tempo de execução de alguns dias pode ser aceitável.

IV. BANCADA EXPERIMENTAL

A abordagem para a validação de benchmarks proposta an-teriormente é ilustrada através de um exemplo concreto de uma benchmark de confiabilidade em sistemas transaccionais. Esta secção apresenta um resumo sobre a benchmark DBench-OLTP [1] e introduz os sistemas usados nas experiências de validação descritas na Secção V.

A. Benchmark DBench-OLTP A DBench OLTP adopta a workload e o ambiente experi-

mental genérico da benchmark para avaliação do desempenho TPC-C [18], e adiciona dois novos elementos: 1) medidas re-lacionadas com a confiabilidade; e 2) uma faultload. De modo a executar a DBench-OLTP, o utilizador deve implementar todos os componentes de acordo com a especificação. Esta secção apresenta uma breve introdução sobre esta benchmark.Uma descrição detalhada pode ser encontrada em [1] e a espe-cificação completa pode ser obtida em [19].

Os principais elementos do ambiente experimental necessá-rio para executar a benchmark DBench-OLTP são: SUB (Sys-tem Under Benchmarking), BT (benchmark target) e BMS (Benchmark Management System).

76 IEEE LATIN AMERICA TRANSACTIONS, VOL. 3, NO. 1, MARCH 2005

O SUB representa qualquer sistema capaz de executar a workload e armazenar todos os dados processados (na prática, qualquer SGBD). Por outro lado, o BT é o motor transaccio-nal, que é na prática o componente que os utilizadores da pre-tendem avaliar. No entanto, as medidas da benchmarkDBench-OLTP caracterizam o desempenho e confiabilidade do SUB e não apenas do BT.

O objectivo do BMS é emular as aplicações cliente e res-pectivos utilizadores, gerir a introdução da faultload e contro-lar todos os aspectos relacionados com a execução da ben-chmark.

De modo a obter as medidas, a execução da benchmarkDBench-OLTP deve incluir duas fases diferentes:

• Fase 1: primeira execução da workload sem injecção de falhas. Esta fase corresponde a uma execução típica da benchmark TPC-C e deve seguir os requisitos definidos em [18]. A Fase 1 é necessária para obter as medidas de desempenho base, que usadas conjuntamente com as res-tantes medidas permitem caracterizar o sistema tanto em termos de desempenho como de confiabilidade.

• Fase 2: nesta fase a workload é executada na presença da faultload de modo a obter as medidas de desempenho na presença de falhas e as medidas de confiabilidade. O objectivo passa por observar o impacto das falhas no processamento de transacções e avaliar aspectos especí-ficos da confiabilidade do SUB. Tal como se pode veri-ficar na Fig. 3, a Fase 2 é composta por várias fracções. Cada fracção corresponde a um intervalo de medição durante o qual é executada a workload e injectada uma ou mais falhas da faultload. De notar que deve ser usada a mesma configuração do SUB nas fases 1 e 2.

Fig. 3. Perfil de execução da benchmark DBench-OLTP.

De modo a evitar que os efeitos das falhas se acumulem en-tre diferentes fracções, o estado do SUB deve ser explicita-mente reposto no início de cada fracção. A medição começa somente depois do SUB atingir a sua capacidade máxima em termos de processamento de transacções. As falhas são injec-tadas algum tempo após o sistema atingir a capacidade máxi-ma de processamento de transacções. Se for detectado algum erro é então iniciado o processo de recuperação necessário. O tempo de recuperação representa o tempo necessário para exe-cutar o procedimento de recuperação do sistema. Se não for detectado qualquer erro ou não for necessária recuperação,

então este tempo não é considerado (igual a 0). Uma vez que, depois de recuperar de uma falha, o sistema necessita de algum tempo para alcançar a capacidade máxima de processamento de transacções, a workload deve continuar a executar durante algum tempo após o final do procedimento de recuperação. Depois de terminada a execução da workload, deve ser execu-tado um conjunto de testes de integridade, de modo a identifi-car possíveis violações da integridade dos dados causadas pela falha (ou falhas) injectadas.

As medidas da benchmark DBench-OLTP encontram-se divididas em três grupos: medidas de desempenho base, medi-das de desempenho na presença de falhas e medidas de confia-bilidade.

As medidas de desempenho base são adoptadas da ben-chmark TPC-C e incluem o número de transacções executadas por minuto (tpmC) e o preço por transacção ($/tpmC). No contexto da benchmark DBench OLTP, estas medidas são obtidas sem a introdução de falhas e pretendem caracterizar o SUB quando optimizado de forma a alcançar o melhor com-promisso entre o desempenho e a confiabilidade (ao contrário da benchmark TPC-C, onde os sistemas são normalmente op-timizados para obter o máximo desempenho). Deste modo, o utilizador da benchmark deve decidir qual a melhor configura-ção do SUB de modo a alcançar este compromisso.

As medidas de desempenho na presença de falhas são: • Tf: número de transacções executadas por minuto na

presença da faultload (mede o impacto das falhas no de-sempenho do sistema e favorece os sistemas com maior capacidade de tolerância a falhas, menores tempos de recuperação, etc.).

• $/Tf: preço por transacção na presença da faultload(mede o beneficio, em termos do preço, da inclusão de

melhores mecanismos de tolerância a falhas).

As medidas de confiabilidade fornecidas são as se-guintes:

• Ne: número de erros de integridade dos dados detectados pelos testes de integridade (mede o impacto das falhas na integridade da base de da-dos).

• AvtS: disponibilidade do ponto de vista do ser-vidor na presença da faultload (caracteriza a quantidade de tempo que o sistema se encontra disponível). Do ponto de vista do servidor, o sis-

tema está disponível quando é capaz de responder a transacções de pelo menos um terminal, dentro do tempo de resposta máximo especificado pela benchmark TPC C para cada tipo de transacção. O sistema está indispo-nível quando não se encontra apto para responder a qualquer terminal.

• AvtC: disponibilidade do ponto de vista dos utilizadores (terminais) na presença da faultload (mede a quantidade de tempo que o sistema está disponível do ponto de vista dos seus clientes). O sistema encontra-se disponível para um determinado terminal se responder às transacções submetidas por esse terminal dentro do tempo de respos-

Fase 1 Fase 2Tempo

Fase 1 Fase 2Tempo

Fracção NFracção 1 Fracção 2 Fracção 3 Fracção NFracção 1 Fracção 2 Fracção 3

Tempo de injecção

Tempo de recuperaçãoFracção X

(Início)Fracção X

(Fim)

Tempo de

aceleração

Tempo extraTempo

de detecção

Início da recuperação

Injecção da falha

Fim da recuperação

Sistema atinge desempenho

máximo

Testes de Integridade

Intervalo de Medição

Tempo de injecção

Tempo de recuperaçãoFracção X

(Início)Fracção X

(Fim)

Tempo de

aceleração

Tempo extraTempo

de detecção

Início da recuperação

Injecção da falha

Fim da recuperação

Sistema atinge desempenho

máximo

Testes de Integridade

Tempo de injecção

Tempo de recuperaçãoFracção X

(Início)Fracção X

(Fim)

Tempo de

aceleração

Tempo extraTempo

de detecção

Início da recuperação

Injecção da falha

Fim da recuperação

Sistema atinge desempenho

máximo

Testes de Integridade

Intervalo de Medição

VIEIRA et al.: HOW TO SPECIFY AND VALIDATE DEPENDABILITY 77

ta máximo definido pela benchmark TPC-C para cada tipo de transacção. O sistema está indisponível se não existir qualquer resposta ou se for devolvido um erro.

A benchmark DBench-OLTP pode ser usada considerando três faultloads diferentes, cada uma baseada numa classe de falhas, nomeadamente: 1) falhas de operador (i.e., erros de administração de base de dados); 2) falhas de software (i.e., defeitos de programação ou bugs ao nível do sistema operati-vo); ou 3) avarias de componentes de hardware (e.g., avarias de discos, cortes de energia e corrupção do meio de armaze-namento). Obviamente, uma faultload genérica que combine as três classes de falhas pode também ser considerada (i.e., as três faultloads definidas pela DBench-OLTP podem ser facilmente combinadas e usadas como uma só).

Os tipos de falhas considerados nas faultloads baseadas em falhas de operador e em avarias de componentes de hardware foram seleccionadas com base numa previsão da sua taxa de ocorrência, aptidão para emular efeitos de outros tipos de fa-lhas, diversidade de impacto no sistema, complexidade do processo de recuperação necessário e portabilidade. Cada faul-tload é composta por um conjunto de várias falhas de cada tipo, injectadas em instantes diferentes.

No que diz respeito às falhas de software, em [3] é proposta uma metodologia para a definição de faultloads baseadas em falhas de software. Esta metodologia baseia-se em estudos prévios sobre a representatividade de falhas de software [20, 21, 22] e numa técnica genérica para a injecção desta classe de falhas [15]. Esta técnica, denominada G-SWFIT (Generic Software Fault Injection Technique), consiste na modificação do código binário de módulos de software através da introdu-ção de alterações específicas. Estas alterações correspondem ao código que seria gerado pelo compilador se a falha de software realmente existisse ao nível do código fonte. Deste modo, a técnica de emulação G-SWFIT e as linhas orientado-res propostas em [3] foram usadas na definição da faultloadbaseadas em falhas de software da benchmark DBench-OLTP. De salientar, que as ferramentas necessárias para injectar falhas de software nos sistemas operativos Windows e Linux são dis ponibilizadas juntamente com a especificação da benchmark.

B. Sistemas Usados na Validação Os exemplos de benchmarking apresentados neste artigo

correspondem ao resultado de um estudo que teve por objecti-vo a validação das propriedades chave da benchmark de confi-abilidade DBench-OLTP

A Tabela I apresenta os sistemas usados (as letras da coluna da esquerda serão usadas mais adiante para referir cada um dos sistemas). A plataforma base consiste numa máquina cons-tituída por um processador Pentium IV a 2 GHz, 512 Mb de memória, quatro discos rígidos 20 GB/7200 rpm. Relativa-mente ao software, foram utilizados dois SGBD diferentes (Oracle 9i e PostgreSQL 7.3) e dois sistemas operativos (Win-dows 2000 e ReadHat Linux 7.3)

Note-se que estes sistemas são bastante representativos das soluções normalmente empregues em aplicações OLTP de pequena e média dimensão.

V. RESULTADOS E VALIDAÇÃO DAS PROPRIEDADES

Tal como mencionado anteriormente, a validação de uma benchmark de confiabilidade consiste em verificar se os seus componentes cumprem um conjunto de propriedades chave.

TABELA ISISTEMAS USADOS NA VALIDAÇÃO

Sistema Sistema Operativo SGBD A Windows 2K Prof. SP 3 Oracle 9i R2 (9.0.2) B RedHat Linux 7.3 Oracle 9i R2 (9.0.2) C RedHat Linux 7.3 PostgreSQL 7.3

Uma vez que a faultload é o componente de natureza mais crítica, estamos particularmente interessados no seu impacto nas propriedades da benchmark como um todo. As sub-secções seguintes apresentam os resultados das experiências organizados por faultload. Note-se que os resultados são dis-cutidos sob o ponto de vista da validação da benchmark. Uma análise dos resultados de um ponto de vista comparativo en-contra-se for a do objective deste trabalho (ver [1] para uma análise comparativa típica).

A representatividade não é abordada nesta secção uma vez que esta propriedade não pode ser verificada experimental-mente. No entanto, a representatividade das classes de falhas consideradas na benchmark DBench-OLTP foi uma questão bastante ponderada durante a sua especificação, tendo sido considerados diversos estudos acerca da representatividade de falhas de operador [11, 12], falhas de software [15, 16, 20, 21, 22] e falhas de hardware [7, 8].

A. Faultload Baseada em Falhas de Operador A Tabela II apresenta um sumário da faultload baseada em

falhas de operador a qual foi definida de acordo com a especi-ficação da benchmark [19]. A Fig. 2 apresenta os resultados experimentais (os números no eixo X identificam a execução da benchmark). Os parágrafos seguintes discutem alguns as-pectos importantes relativos às propriedades da benchmarkDBench-OLTP quando é usada a faultload baseada em falhas de operador.

Portabilidade: motores de bases de dados diferentes po-dem ter conjuntos de tarefas de administração diferentes e consequentemente ter diferentes conjuntos de falhas de opera-dor possíveis. No entanto, tal como se mostra em [12], é pos-sível estabelecer uma equivalência entre muitos tipos de falhas de operador em diferentes SGBD. Os resultados apresentados na Fig. 2 mostram igualmente que é possível implementar a faultload baseada em falhas de operador em sistemas operati-vos e sistemas de bases de dados diferentes.

Repetibilidade: através da análise da Fig. 4 podemos ob-servar que a variação dos resultados relativamente ao desem-penho base (tpmC) está dentro do intervalo definido pela es-pecificação da TPC-C (2%). Relativamente ao desempenho na presença de falhas (Tf), a variação é ligeiramente superior (mas ainda assim sempre inferior a 4%). A variação nas medi-das de disponibilidade é inferior a 0.5%, o que representa um intervalo bastante bom.

78 IEEE LATIN AMERICA TRANSACTIONS, VOL. 3, NO. 1, MARCH 2005

TABELA II FAULTLOAD BASEADA EM FALHAS DE OPERADOR

Tipo de Falha # Falhas % Falhas Encerramento abrupto do SO 10 10.3 Encerramento abrupto do SGBD 10 10.3 Desactivar um conjunto de sessões 5 5.2 Remover uma tabela 12 12.4 Remover o esquema de um utilizador 3 3.1 Remover um ficheiro do disco 27 27.8 Remover um conjunto de ficheiros 27 27.8 Remover todos os ficheiros de um disco 3 3.1

Total 97 100

Escalabilidade: tal como mencionado anteriormente, a faultload baseada em falhas de operador depende da dimensão e configuração do SUB. Em sistemas de grande dimensão, com muitos discos e ficheiros, o número de falhas pode tornar-se extremamente elevado. Nesses casos, apesar do tempo de execução aumentar consideravelmente, a benchmark continua a ser aplicável.

Desempenho Base1797 1774 1788 1779 1780 1762

879 882 858

12,2 12,4 12,3 12,1 12,1 12,2

1,7 1,7 1,7

0

500

1000

1500

2000

1 2 3 4 5 6 7 8 90

5

10

15

20$

tpmC$/tpmC

Oracle 9iWindow s 2K (A)

Oracle 9iRedHat 7.3 (B)

PostgreSQL 7.3RedHat 7.3 (C)

Desempenho com Falhas

1226

1224

1235

1250

1247

1294

256261257

17,517,617,617 17,617,4

5,95,75,8

0

500

1000

1500

2000

1 2 3 4 5 6 7 8 90

5

10

15

20$

Tf$/Tf

Oracle 9iWindow s 2K (A)

Oracle 9iRedHat 7.3 (B)

PostgreSQL 7.3RedHat 7.3 (C)

Disponibilidade

75,4

8

75,5

1

76,5

6

76,3

3

76,2

5

70,4

70,2

3

70,1

5

80,1

4

80,5

3

80,2

3

83,1

5

82,8

7

70,6

3

70,6

8

70,8

883,3

2

75,5

7

50

60

70

80

90

100

1 2 3 4 5 6 7 8 9

% AvtS (Servidor)AvtC (Clientes)

Oracle 9iWindow s 2K (A)

Oracle 9iRedHat 7.3 (B)

PostgreSQL 7.3RedHat 7.3 (C)

Fig. 4. Resultados da benchmark DBench-OLTP usando a faultload baseada em falhas de operador

Não-intrusividade: a emulação de falhas de operador num SGBD pode ser facilmente conseguida através da reprodução de erros típicos do administrador da base de dados. Tais erros podem ser reproduzidos através da execução de comandos SQL típicos. Desta forma não é necessária a introdução de alterações (instrumentação) para injectar falhas desta classe.

Simplicidade de utilização: a implementação da ben-chmark DBench-OLTP usando falhas de operador é uma tare-fa bastante fácil (em parte devido simplicidade da emulação de falhas de operador). Por outro lado, o tempo necessário para a execução da benchmark é bastante baixo, tendo sido possível implementar a benchmark (usando falhas de operador) em 10 dias e executar 9 experiências em 27 dias (resultando numa média de três dias por experiência)

B. Faultload Baseada em Avarias de Componentes de HW A Tabela III sumaria a faultload baseada em avarias de

componentes de hardware. A Fig. 5 apresenta as medidas de desempenho na presença de falhas e a medidas de confiabili-dade. O desempenho base é o já apresentado na Fig. 4.

TABELA III FAULTLOAD BASEADA EM AVARIAS DE COMPONENTES DE HARDWARE

Tipo de Falha # Falhas % Falhas Corte de energia 10 21.3 Avaria de disco 10 21.3 Corrupção do meio de armazenamento 27 57.4

Total 47 100

Nos parágrafos seguintes são discutidos alguns aspectos importantes relativos à validação da benchmark DBench-OLTP usando a faultload baseada em avarias de componentes de hardware.

Portabilidade: a portabilidade dos tipos de avarias de componentes de hardware considerados neste trabalho depen-de apenas no hardware usado pelo SUB. Uma vez que todos os sistemas de computador podem ficar indisponíveis devido a cortes de energia, e possuem discos que podem falhar, a faul-tload em questão pode ser considerada bastante portável. Adi-cionalmente os resultados apresentados mostram que é possí-vel implementar esta faultload em sistemas operativos e siste-mas de bases de dados diferentes.

Repetibilidade: da análise dos resultados da Fig. 5 pode-mos verificar que a variação do desempenho na presença de falhas (menos de 4%) e a variação da disponibilidade (menor que 0,8%) se encontra em intervalos bastante bons.

Escalabilidade: a dimensão da faultload baseada em avari-as de componentes de hardware depende do sistema de arma-zenamento de dados do SUB. Em sistemas de grande dimen-são com centenas de discos rígidos e ficheiros, a faultloadpoderá tornar-se muito grande, o que levará a que a execução da benchmark se torne bastante demorada.

Não-intrusividade: a emulação das falhas de hardware consideradas nesta faultload não exige a alteração ou instru-mentação dos SUB. O desenvolvimento de pequenas aplica-ções é suficiente para a emulação de falhas no disco rígido e corrupção meio de armazenamento. Relativamente às falhas do tipo corte de energia, é necessária a existência de um interface que permita ao BMS efectuar a reinicialização do SUB.

Simplicidade de utilização: a implementação da ben-chmark DBench-OLTP usando avarias de componentes de hardware revelou-se uma tarefa bastante simples, tendo sido

VIEIRA et al.: HOW TO SPECIFY AND VALIDATE DEPENDABILITY 79

necessário apenas cerca de um dia para implementar a faultlo-ad (a implementação restante da benchmark foi reaproveitada das experiências usando falhas de operador) e duas semanas para executar as experiências.

Desempenho com Falhas

1166

1131

11521250

1241

1237

147153150

18,417,617,717,8

1918,7

10,29,810

0

500

1000

1500

2000

1 2 3 4 5 6 7 8 90

5

10

15

20$

Tf$/Tf

Oracle 9iWindow s 2K (A)

Oracle 9iRedHat 7.3 (B)

PostgreSQL 7.3RedHat 7.3 (C)

Disponibilidade

76,3

2

76,3

9

75,3

1

75,3

2

75,5

66,2

9

65,5

5

65,6

8

83,5

83,3

8

83,6

4

83,5

6

84

65,6

8

65,6

8

66,3

5

84,2

8

75,6

3

50

60

70

80

90

100

1 2 3 4 5 6 7 8 9

% AvtS (Servidor)AvtC (Clientes)

Oracle 9iWindow s 2K (A)

Oracle 9iRedHat 7.3 (B)

PostgreSQL 7.3RedHat 7.3 (C)

Fig, 5. Resultados da benchmark DBench-OLTP usando a faultload baseada em avarias de componentes de hardware

C. Faultload Baseada em Falhas de Software O conjunto de falhas de software a considerar nesta faultlo-

ad é fornecido juntamente com a especificação da benchmark(ao contrário faultloads baseadas em falhas de operador e em avarias de componentes de hardware, nesta fautload o utiliza-dor não tem que definir as falhas a injectar). A faultload é composta por mais de 330 falhas abrangendo diversos tipos de falhas de software. A Tabela IV apresenta os tipos de falhas de software consideradas.

A Fig. 6 apresenta os resultados relativos às medidas de-sempenho na presença de falhas e as medidas de confiabilida-de para o SGBD Oracle 9i a correr sobre o Windows 2K. Os resultados do desempenho de base são semelhantes aos apre-sentados na Fig. 3.

Os parágrafos seguintes discutem alguns aspectos importan-tes relativos à validação da benchmark DBench-OLTP usando a faultload baseada em falhas de software.

Portabilidade: a portabilidade da faultload está directa-mente relacionada com a portabilidade da técnica G-SWIT. O trabalho apresentado em [15] mostra que a técnica G-SWFIT é portável: a principal questão prende-se com a definição da biblioteca de operadores de mutação. Essa tarefa dependente principalmente da arquitectura do processador do sistema alvo. O porte da biblioteca para outras arquitecturas exige apenas a definição de novas regras e novas mutações. A técnica em si continua a ser válida e aplicável.

Repetibilidade: tal como podemos observar pela análise da Fig. 6, a variação observada no desempenho na presença de falhas é menor que 2,5% e a variação da disponibilidade é inferior a 1,5%. Ambos são intervalos de variação são bastante

pequenos e abaixo do que é tradicionalmente aceite nas ben-chmarks de desempenho, como as do TPC.

TABELA IV FAULTLOAD BASEADA EM FALHAS DE SOFTWARE

Tipos de falhas Omissão de chamada a função (MFC) Omissão de if” (cond)” à volta de um conj. de instruções (MIA) Omissão de “if (cond) { instruções }” (MIFS) Omissão de “AND EXPR” numa condição de salto (MLAC) Omissão de uma parte localizada do algoritmo (MLPC) Omissão de atribuição de uma expressão a uma variável (MVAE) Omissão de atribuição de um valor a uma variável (MVAV) Omissão de uma inicialização de variável (MVI) Atribuição de um valor errado a uma variável (WVAV) Expressão lógica errada numa condição de salto (WLEC) Expressão aritmética errada num parâmetro de função (WAEP) Variável errada usada num parâmetro de uma função (WPFV)

Escalabilidade: a dimensão desta faultload é maioritaria-mente dependente da complexidade do alvo da injecção de falha (neste caso o sistema operativo) e não está directamente relacionada com o alvo da benchmark (neste caso o motor de bases de dados). No presente caso foi usado um alvo para in-jecção de falhas particularmente complexo (o Windows 2K) e ainda assim as experiências tiveram um custo aceitável tanto em tempo como em esforço para o utilizador da benchmark.

Desempenho com Falhas

1274

1258

1287

17,317,5

17,1

0

500

1000

1500

2000

1 2 30

5

10

15

20$Tf

$/Tf

Disponibilidade78

,1 79

80,1579,2481,12

78,1

5060708090

100

1 2 3

% AvtS (Servidor)AvtC (Clientes)

Fig. 6. Resultados da benchmark DBench-OLTP obtidos usando a faultloadbased a em falhas de software

Não-intrusividade: os resultados das experiências mostram que a penalização no desempenho causada pela técnica usada para injectar as falhas é baixa (menor que 2%). Adicionalmente não foram detectados alterações no comportamento do sistema devido à execução do injector de falhas de software.

Simplicidade de utilização: a emulação e injecção de fa-lhas de software (usando a técnica G-SWFIT ou outra) é uma tarefa que envolve o desenvolvimento de programas relativa-mente complexos. No entanto, uma vez que as ferramentas para este efeito são proporcionadas juntamente com a especifi-cação de benchmark DBench-OLTP, a injecção de falhas de software no contexto desta benchmark torna-se uma tarefa simples. Relativamente ao tempo necessário para executar o

80 IEEE LATIN AMERICA TRANSACTIONS, VOL. 3, NO. 1, MARCH 2005

processo de benchmarking, 6 dias foram suficientes para exe-cutar três experiências completas.

VI. CONCLUSÕES

Este artigo propõe uma abordagem para a validação de benchmarks de confiabilidade para sistemas OLTP. Esta abor-dagem consiste em verificar experimentalmente se a ben-chmark satisfaz um conjunto de propriedades: reproducibili-dade, portabilidade, representatividade, escalabilidade, não-intrusividade, e simplicidade de utilização. Este artigo apre-senta também um conjunto de linhas de orientação para a defi-nição de benchmarks de confiabilidade para sistemas OLTP.

A abordagem proposta para a validação foi verificada atra-vés de um exemplo concreto de uma benchmark de confiabili-dade para sistemas transaccionais – a benchmark DBench-OLTP. Foram conduzidas várias experiências usando diversos sistemas transaccionais. Os resultados obtidos mostram que a benchmark DBench-OLTP cumpre as propriedades chaves mencionadas acima de uma forma bastante satisfatória.

VII. REFERÊNCIAS

[1] M. Vieira, H. Madeira, “A Dependability Benchmark for OLTP Appli-cation Environments”, 29th Intl. Conf. Very Large Data Bases, VLDB2003, Berlin, Germany, Sept., 2003.

[2] K. Buchacker, M. Dal Cin, H.-J. Hoexer, R. Karch, V. Sieh, O. Tschaeche, “Reproducible Dependability Benchmarking Experiments Based on Unambiguous Benchmark Setup Descriptions”, International Conference on Dependable Systems and Networks, DSN-PDS2003, San Francisco, CA, June 22 - 25, 2003.

[3] J. Durães, H. Madeira, “Generic Faultloads Based on Software Faults for Dependability Benchmarking”, IEEE/IFIP Int. Conf. on Dependable Systems and Networks, DSN 2004, Florence, Italy, June, 2004.

[4] A. Kalakech, T. Jarboui, J. Arlat, Y. Crouzet, K. Kanoun, “Benchmark-ing Operating System Dependability: Windows 2000 as A Case Study”, The 10th Intl. Symp. Pacific Rim Depend. Computing, PRDC2004, Ta-hiti, French Polynesia, March 03-05, 2004.

[5] A. Kalakech, K. Kanoun, Y. Crouzet, A. Arlat. “Benchmarking the Dependability of Windows NT, 2000 and XP,” Intl Conf. on Depend-able Systems and Networks (DSN 2004), Florence, Italy, June 2004.

[6] F. Moreira, R. Maia, D. Costa, N. Duro, P. Rodríguez-Dapena, K. Hjortnaes., “Static and Dynamic Verification of Critical Software for Space Applications”. Proc. of the Data Systems In Aerospace (DASIA 2003), 25 June 2003.

[7] Ji J. Zhu, J. Mauro, I. Pramanick, “Robustness Benchmarking for Hardware Maintenance Events”, Intl Conference on Dependable Sys-tems and Networks, DSN2003, San Francisco, CA, June 22 - 25, 2003.

[8] A. Brown, D. A. Patterson, “Towards Availability Benchmarks: A Case Study of Software RAID Systems”, USENIX 2000.

[9] J.-C. Laprie, “Dependable Computing: Concepts, Limits, Challenges”, in Proc. 25th Int. Symposium on Fault-Tolerant Computing (FTCS-25), IEEE Computer Society Press, 1995.

[10] A. Avizienis, J.-C. Laprie, B. Randell, “Fundamental Concepts of De-pendability”, LAAS Research Report, N°1145, April 2001.

[11] A. Brown, D. Patterson, “To Err is Human”, First Workshop on Evalu-ating and Architecting System Dependability (EASY), Göteborg, Swe-den, July 1st, 2001.

[12] M. Vieira, H. Madeira, “Definition of Faultloads Based on Operator Faults for DMBS Recovery Benchmarking”, 2002 Pacific Rim Interna-tional Symposium on Dependable Computing, PRDC2002, Tsukuba, Japan, December 16-18, 2002.

[13] I. Lee, R. K. Iyer, “Software Dependability in the Tandem GUARDIAN System”, IEEE Transactions on Software Engineering, Vol. 21, No. 5, pp. 455-467, May 1995.

[14] J. Gray, “A Census of Tandem Systems Availability Between 1985 and 1990”, IEEE Transactions on Reliability, Vol. 39, No. 4, pp. 409-418, October 1990.

[15] J. Durães, H. Madeira, “Emulation of Software Faults by Selective Mu-tations at Machine-code Level”, 13th IEEE Intl Symposium on Software Reliability Engineering, ISSRE 2002, Annapolis, USA, Nov. 2002.

[16] J. Durães, H. Madeira, “Definition of Software Fault Emulation Opera-tors: a Field Data Study”, IEEE/IFIP International Conference on De-pendable Systems and Networks, DSN2003, San Francisco, CA, June 22 - 25, 2003 (Best Paper Award).

[17] J. Gray (Ed.), “The Benchmark Handbook”, Morgan Kaufmann Pub-lishers, San Francisco, CA, USA, 1993.

[18] Transaction Processing Performance Consortium, “TPC Benchmark C, Standard Specification, V5.1”, 2002, http://www.tpc.org/tpcc/.

[19] M. Vieira, H. Madeira, “DBench – OLTP: A Dependability Benchmarkfor OLTP Application Environments”, Technical Report DEI-006-2002, ISSN 0873-9293, DEI – FCTUC, 2002, available at: http://www.dei.uc.pt/~henrique/DBenchOLTP.htm.

[20] H. Madeira, M. Vieira, D. Costa, “On the Emulation of Software Faults by Software Fault Injection”, Intl. Conf. Depend. Systems and Net-works, New York, USA, June, 2000.

[21] J. Christmansson, R. Chillarege, “Generation of an Error Set that Emu-lates Software Faults”, 26th IEEE Fault Tolerant Computing Sympo-sium, FTCS-26, Sendai, Japan, pp. 304-313, June 1996.

[22] P. Koopman, J. DeVale, “Comparing the Robustness of POSIX Operat-ing Systems”, in Proc. 29th Intl. Symposium on Fault-Tolerant Comput-ing (FTCS-29), Madison, WI, USA, 1999.

VIII. BIOGRAFIAS

Marco Vieira é natural de Ponte de Lima, Portugal. Obteve o grau de Licenciado em Engenharia Informática em 1999 pela Faculdade de Ciências e Tecnologia da Universidade de Coimbra, e o grau de Mestre em Sistemas e Tecnologias da Informação em 2003 pela mesma faculdade.

A sua actividade como investigador é exercida no Centro de Informática e Sistemas da Universidade de Coimbra. Os seus temas de

investigação incluem sistemas confiáveis, benchmarking e bases de dados. Actualmente encontra-se na fase final de preparação da sua dissertação para obtenção do grau de Doutor em Engenharia Informática pela Universidade de Coimbra.

João Durães é natural de Lisboa, Portugal. Obteve o grau de Licenciatura em Engenharia Informática em 1994 pela Faculdade de Ciências e tecnologia da Universidade de Coimbra, e o grau de Mestre em Sistemas e Tecnologias da Informação em 1999 pela mesma faculdade.

A sua actividade como investigador é exercida no Centro de Informática e Sistemas da Universi-dade de Coimbra. Os seus temas de investigação incluem sistemas confiáveis, falhas de software e bases de dados. Actualmente encontra-se na fase

final de Doutoramento em Engenharia Informática pela Universidade de Coimbra.

Henrique Madeira é doutorado em Informática e Professor Associado no Departamento de Engenharia Informática da Faculdade de Ciências e Tecnologia da Universidade de Coimbra. Tem leccionado uma gran-de diversidade de disciplinas em cursos de Licenciatu-ra, Mestrado e Doutoramento na Universidade de Coimbra, leccionando presentemente disciplinas da área de bases de dados. A sua actividade de investiga-ção divide-se entre a Confiabilidade dos Computado-

res e as Bases de Dados, áreas em que é autor/co-autor de cerca de 90 artigos científicos, publicados em conferências e revistas internacionais. É co-autor de metodologias e ferramentas de injecção de falhas (RIFLE e Xception) que têm sido largamente usados internacionalmente, nomeadamente pela Agência Espacial Norte-Americana (NASA) e pela Instituto Nacional de Pesquisas Aeroespaciais (INPE) do Brasil.

VIEIRA et al.: HOW TO SPECIFY AND VALIDATE DEPENDABILITY 81