RECUPERAÇÃO COM BASE EM CHECKPOINTING PARA APLICAÇÕES ORIENTADAS A OBJETOS

Transcrição

1 UNIVERSIDADE DO OESTE PAULISTA FACULDADE DE INFORMÁTICA DE PRESIDENTE PRUDENTE BACHARELADO EM CIÊNCIA DA COMPUTAÇÃO RECUPERAÇÃO COM BASE EM CHECKPOINTING PARA APLICAÇÕES ORIENTADAS A OBJETOS LUCIANO PEREIRA DOMINGUES Presidente Prudente SP 2001

2 UNIVERSIDADE DO OESTE PAULISTA FACULDADE DE INFORMÁTICA DE PRESIDENTE PRUDENTE BACHARELADO EM CIÊNCIA DA COMPUTAÇÃO RECUPERAÇÃO COM BASE EM CHECKPOINTING PARA APLICAÇÕES ORIENTADAS A OBJETOS LUCIANO PEREIRA DOMINGUES Trabalho monográfico apresentado no curso de graduação, Bacharelado em Ciência da Computação, como requisito parcial para sua conclusão. Área de concentração: Ciência da Computação Orientador: Profº. Francisco Assis da Silva - UNOESTE Presidente Prudente SP 2001

3 i Dedicatória Aos meus pais e a minha irmã por todo amor e vida no decorrer desses anos que permitiram a realização deste trabalho e outros, e também a minha família pelo incentivo e apoio.

4 ii Agradecimentos Aos meus pais e a minha irmã por todo o apoio e referência não só nesse, mas em todos os momentos da minha vida. Sinceros agradecimentos a todos que colaboraram na realização deste trabalho, em especial ao Profº Francisco Assis da Silva por toda dedicação e empenho.

5 iii RESUMO Recuperação de processos no âmbito de Tolerância a Falhas tem por objetivo restaurar o estado normal de um sistema computacional interrompido prematuramente durante a sua execução, mediante a ocorrência de falha. A atividade de recuperação de processos objetiva propiciar maior disponibilidade para aplicações computacionais e minimizar o tempo total de execução, na presença de falha. A computação de uma aplicação em execução pode estar exposta à falhas, o uso de técnicas e mecanismos de recuperação faz com que estas sejam toleradas com o restabelecimento do estado normal (livre de erros) da aplicação. Com o uso do mecanismo de checkpointing o estado da aplicação em execução é salvo periodicamente no armazenamento estável. Os vários arquivos que possam vir a ser salvos são conhecidos como checkpoints. Em aplicações orientadas a objetos, dados são representados em forma de objetos, atribuindo uma nova demanda para checkpointing e recuperação. O presente trabalho apresenta um estudo das técnicas e mecanismos de checkpointing e recuperação propostos na literatura como também uma abordagem voltada totalmente para um ambiente orientado a objetos em Java. Foi implementado a partir dos estudos realizados um modelo de classes e métodos de checkpointing e recuperação na linguagem de programação Java para ser utilizado como uma biblioteca de recuperação baseada numa abordagem orientada a objetos.

6 iv ABSTRACT Processes recovery in the scope of fault tolerance has for objective to restore the normal state of a computational system interrupted prematurely during its execution, by means of the fault occurrence. The activity processes recovery objective to propitiate greater availability computational applications and to minimize the total time of execution, in the fault presence. The computation of an application in execution can be displayed to the faults, the use of techniques and recovery mechanisms make with that these are tolerated with the reestablishment of the normal state (free of errors) of the application. With the use of the checkpointing mechanism the state of the application in execution is periodically saved in the steady storage. The some archives that can come to be safe are known as checkpoints. In oriented applications to objects, given are represented in object form, attributing a new demand for checkpointing and recovery. The present work presents a study of the techniques and checkpointing mechanisms and recovery considered in literature as also a boarding directed totaly to a oriented environment the objects in Java. It was implemented from the carried through studies a class model and checkpointing methods and recovery in the programming language Java to be used as a recovery library based on an oriented boarding the objects.

7 v LISTA DE ABREVIATURAS E SIGLAS CPU Central Processing Unit GUI Graphic User Interface JVM Java Virtual Machine TMR Triple Modular Redundancy

8 vi LISTA DE FIGURAS FIGURA 1 Checkpoints periódicos para prover Tolerância a Falhas (PLANK, 1997, p.5)...8 FIGURA 2 Um típico Checkpoint de um único processador (PLANK, 1997, p.6).9 FIGURA 3 Estrutura de um arquivo de checkpoint utilizado pelo mecanismo de checkpointing tradicional...23 FIGURA 4 Estrutura de um arquivo de checkpoint utilizado pelo mecanismo de checkpointing incremental...23 FIGURA 5 Estrutura do salvamento de arquivo de checkpoint pelo mecanismo de checkpointing incremental (1º Arquivo de Checkpoint)...25 FIGURA 6 Estrutura do salvamento de arquivo de checkpoint pelo mecanismo de checkpointing incremental (2º Arquivo de Checkpoint)...26 FIGURA 7 Estrutura do salvamento de arquivo de checkpoint pelo mecanismo de checkpointing incremental (3º Arquivo de Checkpoint)...26 FIGURA 8 Estrutura da recuperação de arquivos de checkpoint pelo mecanismo de checkpointing incremental (3º Arquivo de Checkpoint)...27 FIGURA 10 Estrutura da recuperação de arquivos de checkpoint pelo mecanismo de checkpointing incremental (1º Arquivo de Checkpoint)...28 FIGURA 11 Contêiner resultante da fusão dos arquivos de checkpoint...28 FIGURA 12 Classe Checkpointing...32 FIGURA 13 Classe Gerenciador_Arq...33 FIGURA 14 Classe Time...35 FIGURA 15 Aplicação MultMat fazendo uso das classes desenvolvidas...39 FIGURA 16 Aplicação ShellSort fazendo uso das classes desenvolvidas...41 FIGURA 17 Aplicação HeapSort fazendo uso das classes desenvolvidas...43

9 vii LISTA DE TABELAS TABELA 1 Aplicações utilizadas para os testes funcionais...36 TABELA 2 Avaliação das classes desenvolvidas...43

10 SUMÁRIO RESUMO... III ABSTRACT... IV LISTA DE ABREVIATURAS E SIGLAS... V LISTA DE FIGURAS... VI LISTA DE TABELAS...VII 1 INTRODUÇÃO Trabalhos Correlatos Objetivos do Trabalho Conteúdo desta Monografia CONCEITOS BÁSICOS Checkpoint Checkpointing Checkpointing Incremental Orientação a Objetos Persistência Serialização Linguagem de Programação Java RECUPERAÇÃO Recuperação por Avanço e por Retorno Recuperação por Avanço Recuperação por Retorno Enfoque Baseado em Operação Enfoque Baseado em Estado O PROJETO DESENVOLVIDO Estruturas dos Arquivos de Checkpoint Arquivo de Checkpoint utilizado pelo Mecanismo de Checkpointing tradicional Arquivo de Checkpoint utilizado pelo Mecanismo de Checkpointing Incremental Exemplos do salvamento e recuperação de Arquivos de Checkpoint Mecanismo de Checkpointing tradicional (Salvamento e recuperação de Arquivo de Checkpoint) Mecanismo de Checkpointing Incremental (Exemplo do salvamento de Arquivos de Checkpoint) Mecanismo de Checkpointing Incremental (Exemplo da recuperação de Arquivos de Checkpoint) Descrição das Classes Propostas Classe Checkpointing...29

11 4.3.2 Classe Gerenciador_Arq Classe Time AVALIAÇÃO FUNCIONAL E TESTES Aplicações Exemplo Programa de Multiplicação de Matrizes Método de Ordenação Shell (ShellSort) Método de Ordenação Heap (HeapSort) Utilização das Classes nas aplicações exemplo Avaliação CONCLUSÕES Trabalhos Futuros...44 REFERÊNCIAS BIBLIOGRÁFICAS...45 ANEXOS...48 ANEXO As classes desenvolvidas...49 ANEXO As aplicações...58

12 1 1 INTRODUÇÃO Em sistemas computacionais, falhas toleradas podem ter sua origem tanto em hardware como em software, nos dois casos são igualmente prejudiciais. Assim também as técnicas usadas para dispor mais confiabilidade em sistemas podem ser implementadas tanto em hardware como em software (PORTO, 1991). A obtenção de tolerância a falhas em sistemas computacionais é mais efetivamente alcançada com o uso de mecanismos nos níveis mais baixos de sistemas de computação, apesar disto o tema não se restringe apenas ao hardware (PORTO, 1991). Com a freqüente preocupação em manter a execução de aplicações disponível e longe de anormalidades, a área de tolerância a falhas proporciona o estudo de várias técnicas e implementação de vários mecanismos para prover tolerância. A diminuição do tempo total de execução de aplicações vem sendo a motivação para constantes estudos e implementações de tais técnicas e mecanismos (PORTO, 1991). Na ocorrência de falhas, muitas vezes, aplicações finalizam sua execução prematuramente não obtendo os resultados antes definidos em suas especificações, o emprego de técnicas e mecanismos de recuperação de processos faz com que a execução normal (livre de erros) da aplicação se restabeleça e continue a computação até o seu término na ocorrência de falhas (PORTO, 1991). Recuperação de processos em um sistema computacional baseia-se na restauração do sistema para um estado operacional normal (livre de erros). Se um processo falhou após ter modificado parcialmente uma base de dados (sem concluir a operação), então é importante que todas as modificações feitas na base pelo processo falho sejam desfeitas, ou seja, se o processo executou por algum tempo antes de falhar, basta reexecutar o processo a partir de um ponto prévio onde foi salvo um estado normal de computação. O reinício a partir do ponto da falha, evita a situação de ter a reexecução do processo desde o início da operação, pois isto incorreria em maior tempo consumido e operação custosa (SINGHAL, 1994).

13 2 A recuperação de processos é dividida em dois princípios básicos: a Recuperação por Avanço (forward recovery) e a Recuperação por Retorno ou por Retrocesso (backward recovery), conforme ANDERSON (1981). Os estados salvos durante a execução de um processo, ou conjunto de processos, para os quais o processo pode mais tarde ser recuperado, são conhecidos como pontos de recuperação ou checkpoints. O termo checkpointing é usado para a ação de estabelecer o ponto de recuperação. O estado de um programa executando é periodicamente salvo para um meio estável (armazenamento com segurança) do qual pode ser recuperado depois da ocorrência de uma falha (SINGHAL, 1994; PLANK, 1995). Checkpointing salva um estado volátil do programa (tal como o conteúdo dos registradores e memória) para o armazenamento estável, de forma que, depois de uma falha, o programa pode ser restabelecido para o estado do checkpoint mais recente. Por exemplo, com checkpointing uma vez a cada hora, um programa perderá não mais que uma hora de tempo de reexecução para cada defeito no sistema (PLANK, 1994). Tradicionalmente otimizações de processos de checkpointing são objetivos de programas científicos escritos em Fortran ou C. Tais programas têm freqüentemente grandes regiões de dados somente de leitura. Neste ambiente, uma técnica de otimização efetiva é checkpointing incremental, que usa facilidades de nível de sistema para identificar páginas de memória virtual modificada (PLANK, 1999). Conforme KASBEKAR (1998), em uma abordagem orientada a objetos, é freqüentemente requerido salvar dados de uma aplicação sob a sua execução, mais propriamente com as técnicas de recuperação por retorno. Essa representação de dados feita no armazenamento estável (representação externa) é tipicamente muito diferente da mesma representação de dados executando num programa (representação interna). Quando os dados são requeridos para serem reusados do armazenamento estável, eles necessitam ser convertidos da representação externa para a representação interna. Em um programa orientado a objetos, dados são representados em forma de objetos, e produzir objetos persistentes é uma maneira eficiente de salvar os dados da aplicação no

14 3 armazenamento estável. A persistência pode ser alcançada através da serialização de objetos, um recurso disponível na API de serialização Java. 1.1 Trabalhos Correlatos O trabalho proposto por LAWALL e MULLER (2000), investiga a otimização de checkpointing de programas Java em nível de linguagem. Eles descrevem como sistematicamente associar checkpoint incremental com classes Java. São adicionados métodos para cada classe para salvar e restaurar o estado local. Checkpointing é então executado por um método genérico que invoca o método checkpointing de cada objeto. É proposto neste trabalho usar especialização de programas automáticos para automaticamente otimizar um algoritmo genérico de checkpointing baseado em informações fornecidas pelo programador, sobre os aspectos fixos da estrutura do programa. Especialização de programa otimiza um programa para um contexto específico de uso. Esta técnica restringe a aplicabilidade de um programa, na troca por uma implementação mais eficiente. LAWALL e MULLER (2000) apresentam uma especialização de programas automáticos para otimizar um algoritmo genérico de checkpointing baseado em informações fornecidas pelo programador sobre aspectos fixos da estrutura do programa. Especializando a implementação de checkpointing por base na repetição estrutural e padrões e modificação, são eliminados muitos testes, chamadas virtuais, e passagem de dados não modificados. Especialização de programas é automática, e as transformações do programa podem ser executadas com confiança. Para acessar o enfoque disponibilizado por LAWALL e MULLER (2000), são apresentadas duas especializações de programas. Foi especializado o checkpointing de uma implementação da máquina de análise de programa, a qual executa os tipos de análise que são usados na compilação ou especialização automática de programas. E mais precisamente, para serem analisados os benefícios do enfoque de especialização de programas, foi considerado um programa sintético, no qual podem variar as dimensões e padrões de modificações da estrutura do programa que estará sendo salvo.

15 4 A implementação do checkpointing incremental de programas Java, segundo LAWALL (2000), destaca o checkpointing de um programa orientado a objetos, no qual o estado do programa possa ser recuperado do conteúdo de campos de objetos. Checkpointing incremental em programas Java demanda a atribuição de um flag em cada objeto, indicando se o objeto tem sido modificado desde o checkpointing prévio. A determinação do tempo de estabelecimento dos checkpoints dos objetos e a recuperação de seus estados na definição das classes são obtidas através de encapsulamento, aumentando a segurança global do programa, e simplificando sua manutenção (LAWALL, 2000). No entanto, o modelo de programação genérico introduz overheads (sobrecarga de processamento), sendo que o método checkpointing genérico é independente dos objetos, com os quais interage através de chamadas virtuais (LAWALL, 2000). Chamadas virtuais são menos eficientes do que chamadas de funções diretas. Ainda que o uso de flag reduza o tamanho dos checkpoints, ele não elimina a necessidade de visitar cada objeto definido pelo programa (LAWALL, 2000). Estratégia de checkpointing incremental pode ser otimizada pela criação manual de funções especializadas para retomar a estrutura de objetos no programa. Quando alguns objetos não foram alterados os checkpoints não precisam ser salvos, todo código relativo ao método checkpointing desses objetos, podem ser removidos. Contudo, muitas rotinas de checkpointing especializadas podem ser necessárias, para considerar a extensão da estrutura de objeto composta usada em diferentes fases do programa. Quando o programa é modificado, essas rotinas manualmente otimizadas devem necessitar ser completamente reescritas. Assim, enquanto esses tipos de otimizações podem render grande aumento de desempenho do programa, conduzem a mão-de-obra trabalhosa e propensa a erros (LAWALL, 2000).

16 5 1.2 Objetivos do Trabalho O presente trabalho tem o objetivo de estudar técnicas e mecanismos de checkpointing e recuperação, como também implementar algumas classes para serem utilizadas como se fosse uma biblioteca de checkpointing e recuperação voltada para um ambiente orientado a objetos. O ambiente definido para o desenvolvimento do projeto é o Java, devido à observação de algumas importantes características da linguagem: implementação usando o JDK 1.2.2; ferramenta de apoio ao desenvolvimento: KAWA; recursos de serialização (API de serialização JAVA); possibilidade de usar as classes em diversas plataformas (Windows 9.x, Linux, etc). Segundo LAWALL (2000, p.1), programas escritos em uma linguagem orientada a objetos, tal como Java, atribui novas demandas de checkpointing: Estilo de programação orientado a objetos propicia a criação de muitos objetos pequenos. Cada objeto pode ter alguns campos que são somente de leitura, e outros que são freqüentemente modificados; O programador de Java não tem nenhum controle sobre a alocação de objetos. Assim, é impossível assegurar que freqüentemente objetos modificados sejam todos armazenados na mesma página de memória. Além disso, uma única página pode conter objetos vivos (live) e objetos que aguardam o coletor de lixo para serem desalocados da memória (garbage collection); Programas Java são executados em uma máquina virtual que suporta processos simultâneos. Desde então, Java encoraja paralelismo como um método de engenharia de software, bibliotecas como GUI Graphic User Interface criam muitos processos cujos estados nem sempre são proveitosos em um checkpoint. Também, distribuição de objeto não é usualmente gerenciada conforme no princípio de processos, neste caso adiciona memória desnecessária para o checkpoint.

17 6 1.3 Conteúdo desta Monografia Esta monografia está organizada da seguinte forma: no capítulo 1, encontra-se uma introdução da pesquisa realizada, trabalhos correlatos, objetivos e o conteúdo da monografia. No capítulo 2 e 3 são apresentados conceitos básicos da área onde foi enfocada toda a pesquisa para a construção do trabalho. O capítulo 4 mostra as características do projeto prático desenvolvido, os mecanismos que foram implementados, as estruturas dos arquivos de checkpoint e a descrição das classes desenvolvidas. No capítulo 5 são mostradas as aplicações que foram usadas de exemplo, formas de execução e utilização das classes desenvolvidas, como também a avaliação dos mecanismos implementados. Finalmente no capítulo 6 estão algumas conclusões extraídas sobre o trabalho realizado.

18 7 2 CONCEITOS BÁSICOS Neste capítulo são apresentados conceitos de checkpoint, checkpointing e checkpointing incremental num enfoque de linguagem seqüencial. Vale ressaltar que estas informações serviram para obter conhecimento teórico destes assuntos, o que ajudou na concepção do trabalho prático desta dissertação que envolve um enfoque de linguagem orientada a objetos. 2.1 Checkpoint Checkpoint ou ponto de recuperação é o estado salvo durante a execução de um processo ou aplicação, podendo mais tarde ser utilizado para a recuperação do mesmo processo ou aplicação na ocorrência de falhas (SINGHAL, 1994; PLANK, 1995). 2.2 Checkpointing O termo checkpointing é usado para a ação de estabelecer o ponto de recuperação ou checkpoint. O estado de um programa em execução é periodicamente salvo para um meio estável (armazenamento com segurança) do qual pode ser recuperado depois da ocorrência de um defeito (SINGHAL, 1994; PLANK, 1995). O principal uso para checkpointing com recuperação por retorno é prover tolerância a falhas (FIGURA 1), onde em um intervalo periódico, a aplicação armazena checkpoints no armazenamento estável. Se uma falha acontece no sistema e força a aplicação a terminar prematuramente, a aplicação pode reiniciar de seu mais recente checkpoint, perdendo, no máximo, um intervalo da computação (PLANK, 1997). Como um método de tolerância a falhas, checkpointing é muito poderoso porque não faz nenhuma distinção sobre o tipo de falhas que podem ocorrer. Contanto que o estado que foi salvo no checkpoint esteja livre de falhas, pode tolerar falhas de hardware, falhas de software, e até mesmo falhas provocadas por variação elétrica (PLANK, 1997).

19 8 Checkpoints periódicos Estado Inicial Recuperação Estado Final FIGURA 1 Checkpoints periódicos para prover Tolerância a Falhas (PLANK, 1997, p.5). Estabelecer um checkpoint transparene de um processo em uma máquina de um único processador é conceitualmente simples (FIGURA 2). Quando um programa está em execução, seu estado é composto dos valores em memória, estado dos registradores da CPU, e o estado do sistema operacional (inclusive o sistema de arquivos). Normalmente, a memória é dividida em quatro partes: código executável, variáveis globais, área de memória usada pela alocação de variáveis dinâmicas (heap) e a pilha (stack). Destes, as variáveis globais, heap e stack precisam ser armazenados juntos com os estados dos registradores em um checkpoint. São nas variáveis globais, heap, stack e registradores que se pode obter o estado atual da computação da aplicação em execução no momento que for estabelecer o checkpoint. E é com estes dados armazenados no checkpoint que torna possível reiniciar a aplicação restaurando o sistema como ele estava no momento da execução do checkpointing (PLANK, 1997, p.6).

20 9 Stack :. Espaço de endereços do programa do usuário :. Heap Globals Code RD Espaço de endereços do Kernel RI... FC FF Memória Registradores Arquivo de Checkpoint FIGURA 2 Um típico Checkpoint de um único processador (PLANK, 1997, p.6). Conforme PLANK (1997, p.1), Checkpointer é uma ferramenta que efetua o estabelecimento do checkpoint: salva o estado do programa em execução. Quando o checkpointer é implementado no sistema operacional, então informações suficientes podem ser armazenadas com o checkpoint para restabelecer a visão que o programa tinha do sistema operacional no momento do checkpointing. Quando o checkpointer é implementado em nível de usuário, então não tem os privilégios para restabelecer o sistema operacional, mas apenas pode tentar fazer o sistema operacional se comportar como estava no momento que o checkpoint foi estabelecido. Na ocorrência da execução de sistemas com várias CPUs, existe uma variação em relação ao estabelecimento de arquivos de checkpoint. Sistema de checkpointing com múltiplas CPUs e múltiplas memórias são mais complexos, porque sincronizar todas as CPUs é uma atividade muito custosa. Entretanto, na ausência de sincronização, surge o problema de consistência de checkpointing (PLANK, 1997, p.6).

21 Checkpointing Incremental Checkpointing incremental baseia-se na não repetição estrutural e padrões de modificação, procurando sempre eliminar testes, chamadas virtuais e passagem de dados não modificados. Cada arquivo de checkpoint contém somente as páginas que tem sido modificadas desde o checkpoint prévio (LAWALL, 2000). Este princípio de checkpointing faz a tomada de um novo tipo de arquivo de checkpoint, ou seja, checkpoint somente das informações alteradas desde o checkpoint prévio, sendo que, a porção inalterada pode ser restabelecida de arquivos de checkpoints anteriores. Checkpointing incremental usa páginas de proteção de hardware para identificar a porção inalterada do checkpoint. Salvando somente a porção que foi alterada, reduz o tamanho de cada checkpoint e conseqüentemente reduz a sobrecarga de processamento (LAWALL, 2000). Em arquivo de checkpoint não incremental estão todas as informações desde o primeiro checkpoint, portanto os arquivos antigos podem ser apagados, só sendo necessário manter o mais recente. Ao contrário disso, o arquivo de checkpoint incremental é a porção de informações que foram modificadas desde o checkpoint prévio. Na aplicação de checkpointing incremental os arquivos antigos não podem ser apagados, porque o estado de dados do programa é espalhado em vários arquivos de checkpoint. O tamanho cumulativo de arquivos de checkpoint incremental aumentará a uma taxa fixa com o passar do tempo, uma vez que muitos valores atualizados podem ser salvos para a mesma página. Para colocar um limite no tamanho cumulativo dos arquivos de checkpoint incremental, é necessário fundir todos arquivos velhos de checkpoint em um arquivo novo, e então descartar os arquivos velhos (PLANK, 1995).

22 Orientação a Objetos O paradigma da orientação a objetos tornou-se referência obrigatória para profissionais atuando na concepção e construção de aplicações nos mais variados campos. O uso eficiente de técnicas e ferramentas orientadas a objetos pode trazer um ganho de eficiência aos programadores pela redução no tempo de desenvolvimento e manutenção e pelo reaproveitamento de código (UNICAMP, 2001b). A idéia fundamental de linguagens orientadas a objetos é a possibilidade de combinar em um único registro campos que conterão dados e métodos que operaram estes campos de dados. Tal conceito assim estruturado é definido como classe (MAGALHÃES, 1999). Uma classe é considerada um tipo de dado como os tipos que existem pré-definidos em compiladores de diversas linguagens de programação. Uma variável declarada por uma classe é chamada de objeto (MAGALHÃES, 1999). Objetos podem conter objetos, ou seja, os atributos de um objeto podem ser objetos, da mesma classe ou não. Objetos possuem um estado e um comportamento. Um objeto pode ser visto como um record (registro), só que com uma tabela de funções chamadas para o seu próprio uso (MAGALHÃES, 1999). A programação orientada a objeto oferece uma maneira de relacionar classes umas com as outras por meio de hierarquias. Este processo está presente quando dividimos classes em subclasses, mantendo-se o princípio de que cada subclasse herda as características da classe da qual foi derivada, este é o conceito conhecido como herança (MAGALHÃES, 1999). Conforme UFPEL (2001), O conceito de encapsulamento está intimamente ligado com o conceito de abstração. Num dado objeto somente interessa ao cliente as funções que ele executa e não a implementação da mesma. Na parte de interface temos a descrição das operações que o objeto executa, o que é acessível ao cliente, a implementação de tais operações fica encapsulada e só é visível ao próprio objeto. Se precisarmos mudar o valor de alguma variável de instância de um objeto, devemos enviar uma mensagem que recebe um valor como argumento e faz a alteração. Não podemos acessar variáveis de instância

23 12 diretamente. Desta forma, os campos estarão escondidos para nós, o que previne alterações acidentais. Dizemos então que as variáveis de instância e seus métodos estão encapsulados em uma única entidade. As palavras encapsular e esconder são termos técnicos da definição de linguagens orientadas a objeto. Se alguma modificação ocorrer em variáveis de instância de um certo objeto, sabemos exatamente quais métodos interagiram com elas: são os métodos desse objeto. Nenhum outro método pode acessar esses dados. Isso simplifica a escrita, manutenção e alteração de programas. Um bom exemplo de encapsulamento seria um disco rígido. A interface do disco rígido deixa acessível ao computador (cliente) suas funções de leitura e escrita, os dispositivos mecânicos e eletromagnéticos que o HD utiliza para realizar tais operações não fica acessível ao seu cliente estando assim encapsulados. Polimorfismo em linguagens de programação orientadas a objetos é o uso de um único nome para definir várias formas distintas. Em linguagens de programação, polimorfismo é uma facilidade que permite que dois ou mais objetos diferentes respondam a mesma mensagem. O objeto emissor não precisa saber como o objeto receptor implementa a mensagem. Apenas os objetos receptores devem se preocupar com isso. Uma analogia ao polimorfismo é o sinal dos colégios. Embora seja um único sinal, ele significa coisas distintas para cada aluno: uns vão para casa, outros para biblioteca e terceiros voltam para sala de aula, todos respondem ao sinal, mas cada um do seu jeito. O polimorfismo permite um objeto emissor comunicar-se com um objeto receptor sem ter que entender que tipo de objeto ele é, apenas o objeto receptor deve reconhecer a mensagem (UFPEL, 2001).

24 Persistência A persistência em linguagens de programação orientada a objetos, é a habilidade dos objetos existirem além do tempo de vida do programa, no qual eles foram criados. Em Java o tempo de vida de um objeto inicia quando ele é criado pelo operador new, até ser destruído pelo garbage collector da JVM Java Virtual Machine. A habilidade dos objetos persistirem é conseguida através da serialização (MATHIS, 1997). De acordo com JORDAN (1998), os princípios de persistência de objeto são independentes de linguagem e podem ser utilizados a qualquer linguagem específica. Em resumo, eles são como segue: O tempo de vida dos objetos é determinado pela referência de outros objetos persistentes. Salvando um objeto no armazenamento estável também deve salvar todos os objetos que são referenciados por ele. Assim, um objeto torna persistente se é explicitamente salvo no armazenamento estável, ou se é referenciado por outro objeto persistente; Durante a execução normal de um programa com objetos persistentes e nãopersistentes, não deveria ser possível distinguir se o código está operando em um objeto persistente ou em um objeto não persistente. 2.6 Serialização Serialização de objetos é o mecanismo que permite converter a representação de um objeto em memória para uma seqüência de bytes, com isso possibilitando o transporte das informações do mesmo objeto para um meio onde confirme sua persistência (UNICAMP, 2001a). O processo de capturar o estado de um objeto é chamado de serialização de objeto (serializing), e o processo de recriar o objeto a partir do estado capturado é chamado de-serialização de objeto (deserializing). Quando um objeto é de-serializado, um novo objeto é criado e seu estado é estabelecido pelo estado representado pela seqüência de bytes; efetivamente é criada uma cópia do objeto serializado, ao invés de sobrescrever o estado de um objeto existente (HANSEN, 1999).

25 14 Serialização é uma técnica normalmente usada para transmissão de objetos através de aplicações, gravação de objetos em disco, transmissão via rede, etc (UNICAMP, 2001a). 2.7 Linguagem de Programação Java Com o surgimento da linguagem de programação Java desenvolvida pela Sun MicroSystems, possibilitou-se uma nova abordagem de programas, isto é, depois de compilados estes podem ser executados em qualquer plataforma (WALNUM, 1997). Conforme MAGALHÃES (1999, p. 3), java é excelente para desenvolver aplicações comerciais e para ser usada em universidades. Java é a fusão de várias tecnologias que vêm sendo desenvolvidas na área de computação, de modo que estudantes dessa linguagem têm a oportunidade de tomar contato com vários tópicos recentes: programação concorrente, sistemas distribuídos, orientação a objetos, protocolos da Internet e uma série de outros assuntos fáceis de praticar nessa linguagem. A escolha de Java como ambiente de desenvolvimento para a implementação do presente projeto de pesquisa se deve a alguns fatos observados e mostrados logo abaixo, de acordo com UNICAMP (2001b): as contribuições de Java como linguagem e ambiente de programação são aplaudidas igualmente por desenvolvedores e pesquisadores. Jamais uma linguagem reuniu rapidamente tantas características favoráveis além do apoio de instituições importantes, estando prestes a se tornar um padrão para o desenvolvimento com objetos; java oferece quase todo o potencial de C++ mas de uma forma bem uniforme, muito clara e sem idiossincrasias 1 ; java é mais simples e mais fácil de ser compreendida que C++; java foi projetada com base em 10 anos de experiência de C++, e aproveita suas melhores características; 1 Disposição do temperamento de um indivíduo para sentir, de um modo especial e privativo dele, a influência de diversos agentes. Reação individual própria a cada pessoa;

26 15 java oferece tratamento de exceções hierárquicas, essencial para a robustez de sistemas complexos; memória dinâmica é gerenciada automaticamente, diminuindo o potencial para erros; muitas características estão incluídas diretamente na linguagem/api padronizada, e não em bibliotecas ou ferramentas externas. Isso simplifica seu aprendizado e uso, além de garantir a portabilidade: gerenciamento de threads para programação concorrente; gráficos e interfaces gráficas; conexão em rede, facilidades cliente-servidor; polimorfismo; gerenciamento de compilação de módulos (classes); programas Java podem ser executados em todas as plataformas significativas sem necessidade do código-fonte ou recompilação; a uniformidade dos conceitos de Java permite a integração em aplicações de conceitos modernos como componentes, invocação remota, reflexão/introspecção, validação e conectividade a bancos de dados; o potencial de Java se aplica em várias direções, de aplicações convencionais ou distribuídas na Internet a programas embutidos (embedded); programas Java podem ser interpretados ou executados. Java é uma linguagem de programação quase que totalmente orientada a objetos. Algumas exceções como tipos simples e primitivos (números e variáveis booleanas) não são objetos por questões de desempenho (MAGALHÃES, 1999). A portabilidade é uma das características presentes na linguagem Java. Dessa forma, checkpointing de nível de linguagem para Java provê independência de máquina virtual. Checkpointing é conceitualmente semelhante a serialização, a conversão de uma estrutura de objeto em uma representação plana (flat). Em Java, serialização é implementada usando reflexão em tempo de

27 16 execução. Reflexão é usada para determinar a estrutura estática de cada objeto (seu tipo, nome do campo, etc.), e para ter acesso aos valores de campos registrados (LAWALL, 2000).

28 17 3 RECUPERAÇÃO Na área de Tolerância a falhas, recuperação de processos em um sistema computacional provê a restauração do sistema para um estado operacional normal. Recuperação pode ser tão simples como reiniciar um computador com falha ou reiniciar um processo falho. Entretanto, vários sistemas como aplicações científicas de longa duração, exigem uma implementação mais genérica e complexa da recuperação de processos com diferentes atribuições e funcionalidades (CECHIN, 1998). A complexidade da recuperação de processos, advêm da necessidade de gerenciamento dos recursos utilizados após a ocorrência de uma falha, ou seja, recursos devem ser liberados no caso de alocação de espaços de memória, alterações devem ser desfeitas no caso de banco de dados. Por exemplo, se um processo falhou após ter modificado uma base de dados, é importante que todas as modificações feitas pelo processo falho sejam desfeitas (CECHIN, 1998). 3.1 Recuperação por Avanço e por Retorno Quando existe a possibilidade de estimar a natureza das falhas completamente e com precisão, pode-se remover todos os erros causados por elas. Então é possível recuperar um processo falho através da recuperação por avanço, trazendo-o para um estado livre de falhas. A técnica de recuperação por avanço restringe sobrecarga de processamento somente para os componentes falhos de um processo (CECHIN, 1998). Quando não é possível prover a natureza das falhas com precisão, não sendo possível identificar os erros por elas causados e não sendo possível remover todos os erros no estado do sistema, deve-se recorrer aos princípios da recuperação por retorno. Esse mecanismo conduz o processo, ou um conjunto de processos a um estado prévio livre de falhas, salvo durante a execução normal do sistema, possibilitando que as computações que apresentam erro sejam refeitas (CECHIN, 1998). O projeto da recuperação de erros por retorno é mais simples que recuperação por avanço, pois a recuperação por avanço depende de uma análise

29 18 prévia das falhas a serem suportadas, enquanto que na recuperação por retorno não é necessário conhecê-las. O mecanismo de recuperação por retorno é genérico e efetivo para falhas do tipo temporárias (CECHIN, 1998). A técnica de recuperação por avanço compreende em remover ou isolar erros específicos, somente as partes do estado que apresentam erros precisam ser corrigidas. Entretanto, essa técnica só pode ser empregada onde os danos podem ser estimados corretamente. Por conseguinte, não é um conceito tão geral quanto à recuperação por retorno, não pode ser empregado como um mecanismo geral para recuperação de erro (SINGHAL, 1994). 3.2 Recuperação por Avanço Conforme CECHIN (1998, p.32), a recuperação de erros por avanço visa remover ou isolar erros específicos, de forma que a computação normal possa ser retomada. Isto pode ser obtido através da correção seletiva dos estados do sistema que apresentaram erros. A recuperação por avanço requer uma previsão precisa da extensão dos danos causados pelas diversas falhas. Enquanto a recuperação por retorno é uma técnica que pode ser utilizada de forma genérica, com a recuperação por avanço não ocorre o mesmo: o alcance das falhas deve ser limitado e tolerado dentro destes limites de forma que o seu tratamento seja transparente para o resto do sistema. A noção de confiabilidade requer que um sistema possua uma especificação com relação a qual os resultados da computação possam ser verificados. A uma ação atômica, estão associados estados bem definidos no início e no final da atividade. A especificação de uma ação atômica corresponde à relação que deve existir entre estes dois estados, sendo estes totalmente independentes das atividades internas da mesma. A especificação e o encapsulamento associados com as ações atômicas fornecem um contexto para a aplicação de técnicas de detecção de erro e determinação dos danos. Além disso, uma vez que as ações atômicas delimitam a propagação dos erros causados pela comunicação entre processos, elas também fornecem o confinamento de danos (CECHIN, 1998, p.32). As ações atômicas são associadas com as exceções de forma a implementarem a recuperação por avanço. Quando é detectada uma falha dentro de uma ação atômica, esta ativa uma exceção. O tratador desta exceção, localizado na ação atômica, deverá implementar mecanismos de tolerância a

30 19 falhas como a recuperação. Caso o tratador da exceção seja bem sucedido, a ação atômica produzirá os resultados esperados, conforme sua especificação; caso o tratador não tenha sucesso, a ação atômica encerrará sua atividade sinalizando uma exceção (CECHIN, 1998, p.32-33). A integração do mecanismo de imprecisão e das técnicas de recuperação permite uma melhora nas características de tolerância a falhas do sistema. Durante a execução de uma tarefa, ao final de cada ciclo de cálculo, são registrados os resultados intermediários (valores imprecisos) e seus respectivos indicadores de precisão (para avaliação futura dos resultados). Estes registros podem ser comparados a pontos de recuperação. Se a tarefa de cálculo chega ao final antes de atingir o seu limite de tempo, é obtido um resultado preciso e a falha de temporização não ocorre. Caso a falha ocorra, pode-se tomar o último resultado impreciso obtido. Esta recuperação é do tipo por avanço (OLIVEIRA, 1997). De acordo com CECHIN (1998, p.35), são apresentadas algumas características da recuperação por avanço: a recuperação por avanço apresenta um desempenho melhor que a recuperação por retorno pois não existe a necessidade de reprocessamento; entretanto, a recuperação por avanço requer um conhecimento prévio da natureza das falhas. Desta forma, um sistema pode contar com a recuperação por avanço para algumas falhas, mas sempre deverá existir um tratador genérico do tipo recuperação por retorno; para que a recuperação por avanço seja implementada, os sistemas devem prover algum mecanismo de confinamento de danos.

31 Recuperação por Retorno A recuperação por retorno baseia-se na restauração de um processo para um estado anterior livre de erros (RANDELL, 1979). A recuperação por retorno é efetiva para falhas do tipo temporárias. O mecanismo de recuperação por retorno salva periodicamente o estado de um processo durante uma execução livre de falha e, após uma falha, reinicia de um destes estados, reduzindo a quantidade de trabalho perdido (CECHIN, 1998). Para estabelecer o sistema a um estado consistente durante as ações da recuperação por retorno, é necessário que o sistema antes da falha tenha gravado as informações relativas ao processamento em memória estável. Existem duas maneiras para implementar recuperação por retorno, uma delas é o enfoque baseado em operação e outra é o enfoque baseado em estado (LEE, 1990) Enfoque Baseado em Operação No enfoque baseado em operação, todas as modificações efetuadas nos estados dos processos são registradas com um nível de detalhamento tal que permita desfazer as modificações, levando o sistema a um estado anterior. Esta forma de registro da atividade do sistema é denominada de audit trail ou log (RANDELL, 1979; CECHIN, 1998). Considere-se uma transação baseada em um ambiente no qual transações atualizam um banco de dados. Em tal ambiente, é desejável a capacidade de concluir uma atualização (commit) ou desfazer atualizações baseadas em transação. Commit é uma ação que indica que o processo ou transação de atualização do objeto foi completada com sucesso, e então as mudanças feitas no banco de dados podem tornar-se permanentes. Se uma transação não realizou um commit, as atualizações do banco de dados deveriam ser desfeitas. Além disso, se uma parte do banco de dados está perdida devido a um erro de mídia de armazenamento, deveria ser passível ao banco de dados reconstruir essa parte (SINGHAL, 1994).

32 21 Esta técnica é especialmente utilizada em ambientes transacionais (que utilizam transações atômicas), primitivas do tipo DO para realizar uma transação e gravar um registro na memória estável, REDO para refazer uma transação registrada pela primitiva DO, e UNDO para desfazer uma transação registrada pela primitiva DO (CECHIN, 1998) Enfoque Baseado em Estado No enfoque baseado em estado para recuperação, o estado completo de um processo é salvo em uma memória estável quando um ponto de recuperação é estabelecido e a recuperação de um processo envolve restabelecer o seu último estado salvo e retomar a computação a partir deste ponto. A ação de salvamento dos estados dos processos (pontos de recuperação) é denominado de checkpointing ou taking a checkpoint (SINGHAL, 1994). O procedimento de restaurar um processo para um estado anterior é denominado de rolling back. O rolling back de um processo e o reinício de sua computação, a partir de um estado anterior incorre em overhead (sobrecarga de processamento) e atrasa o tempo total de término da execução do processo. É habitual estabelecer muitos checkpoints durante a execução de um processo, possibilitando assim a recuperação por retorno a um estado armazenado recentemente (SINGHAL, 1994).

33 22 4 O PROJETO DESENVOLVIDO O projeto desenvolvido foi implementado utilizando as técnicas e mecanismos de recuperação por retorno. Simplicidade e efetividade são características desta técnica genérica de recuperação de erros (SINGHAL, 1994; CECHIN, 1998). Foram implementadas algumas classes e métodos para prover checkpointing e recuperação de objetos. Características do projeto desenvolvido: mecanismo checkpointing tradicional; mecanismo checkpointing incremental; checkpointing inibido por controle de tempo; não transparente ao programador; requer algum esforço de programação; inclusão de chamadas dos métodos para estabelecer os checkpoints e prover recuperação. 4.1 Estruturas dos Arquivos de Checkpoint Algumas estruturas de arquivos de checkpoint foram construídas e implementadas. O estado da aplicação é representado em forma de objetos, portanto um ou mais objetos devem ser salvos em um arquivo de checkpoint. O conceito de persistência de objetos diz respeito à possibilidade dos objetos serem salvos e permanecerem em armazenamento estável, além do tempo de vida da aplicação que os criou. O uso da classe HashMap (um tipo contêiner) existente na linguagem Java permite o agrupamento de vários objetos em um único objeto da classe HashMap. Com isso a estrutura do tipo contêiner (formada em instância pela classe HashMap) fornece uma estrutura para colocar em conjunto vários objetos que podem ser salvos em arquivo de checkpoint. Nas seções seguintes são mostradas as estruturas de arquivos de checkpoint com o uso de um objeto contêiner da linguagem Java. Algumas estruturas foram influenciadas por trabalhos relacionados aos trabalhos estudados, tais como LAWALL (2000) e HANSEN (1999).

34 Arquivo de Checkpoint utilizado pelo Mecanismo de Checkpointing tradicional A estrutura de arquivo de checkpoint utilizado pelo mecanismo de checkpointing tradicional, a cada tomada do estado da aplicação guarda todas as informações da aplicação representadas em forma de objetos desde o início de sua execução. A estrutura do referido arquivo é mostrada na FIGURA Obj1 Obj2 Obj3 FIGURA 3 Estrutura de um arquivo de checkpoint utilizado pelo mecanismo de checkpointing tradicional Arquivo de Checkpoint utilizado pelo Mecanismo de Checkpointing Incremental A estrutura mostrada na FIGURA 4 traz o modelo da estrutura para arquivos de checkpoint que utilizam o mecanismo de checkpointing incremental. Um dos objetos colocados no contêiner principal é um objeto do tipo contêiner que recebe valores ( 1 -> para estado modificado e 1 -> para estado não modificado) que indicam o estado de modificação dos outros objetos (Obj1, Obj2, Obj3) C Obj1 Obj2 Obj FIGURA 4 Estrutura de um arquivo de checkpoint utilizado pelo mecanismo de checkpointing incremental

35 Exemplos do salvamento e recuperação de Arquivos de Checkpoint Como já foi visto na seção 4.1, as informações e as estruturas utilizadas no salvamento e recuperação de arquivos de checkpoint dependem do mecanismo de checkpointing que é empregado. No mecanismo de checkpointing tradicional os objetos definidos para o salvamento no arquivo de checkpoint serão salvos independentemente de modificações, diferente do que acontece no mecanismo de checkpointing incremental, onde existe a necessidade de comparar constantemente o estado dos objetos que são salvos periodicamente Mecanismo de Checkpointing tradicional (Salvamento e recuperação de Arquivo de Checkpoint) No salvamento do estado do objeto ou objetos de uma aplicação em um arquivo de checkpoint na abordagem tradicional de checkpointing, o estado do objeto ou objetos não é comparado com seu estado anterior salvo, no que diz respeito ao acontecimento de modificações. A estrutura utilizada de arquivo de checkpoint neste caso foi mostrada na FIGURA 3 na seção Na recuperação da aplicação após uma falha, o estado normal de execução é restabelecido do último arquivo de checkpoint salvo Mecanismo de Checkpointing Incremental (Exemplo do salvamento de Arquivos de Checkpoint) As três figuras a seguir (FIGURAS 5, 6, 7) mostram um exemplo de uma seqüência do salvamento dos objetos de uma aplicação durante sua execução utilizando o mecanismo de checkpointing incremental. Na posição 0 (zero) do contêiner principal existe o contêiner C (cabeçalho) que guarda os valores que indicam o estado de modificação dos objetos (Obj1, Obj2, Obj3), o valor 1 para cada posição do contêiner C (cabeçalho) indica que os objetos do contêiner principal foram modificados e serão salvos no arquivo de checkpoint, e o valor 1 indica que os objetos não foram modificados e não serão salvos no arquivo de checkpoint. As posições no contêiner C (cabeçalho) onde são colocados os valores do estado de modificação

36 25 de cada objeto são correspondentes com as posições dos próprios objetos no contêiner principal. A FIGURA 5 mostra a forma como o 1º arquivo de checkpoint será salvo, três objetos são modificados (Obj1, Obj2, Obj3) e suas correspondentes posições no contêiner C (cabeçalho) recebem o valor 1 (indicando a ocorrência da modificação) C Obj1 Obj2 Obj º Arquivo de Checkpoint FIGURA 5 Estrutura do salvamento de arquivo de checkpoint pelo mecanismo de checkpointing incremental (1º Arquivo de Checkpoint) Na FIGURA 6 é mostrado o 2º arquivo de checkpoint salvo com apenas o Obj3, pois somente este foi modificado, e sua posição correspondente no contêiner C (cabeçalho) recebe o valor 1. Os valores do estado de modificação dos outros objetos (Obj1, Obj2) que não foram modificados são 1, colocados nas posições 1 e 2 do contêiner C, que correspondem respectivamente as posições de Obj1 e Obj2 no contêiner principal.

37 26 C 0 Obj º Arquivo de Checkpoint FIGURA 6 Estrutura do salvamento de arquivo de checkpoint pelo mecanismo de checkpointing incremental (2º Arquivo de Checkpoint) No 3º arquivo de checkpoint (FIGURA 7) os Obj1 e Obj3 foram modificados e serão salvos respectivamente nas posições 1 e 3 do contêiner principal. O contêiner C (cabeçalho) nas posições 1 e 3 recebe o valor 1, e na posição 2 o valor 1, que representa o estado de não modificação do Obj2 e sua ausência no contêiner principal. 0 C 1 3 Obj1 Obj º Arquivo de Checkpoint FIGURA 7 Estrutura do salvamento de arquivo de checkpoint pelo mecanismo de checkpointing incremental (3º Arquivo de Checkpoint) Mecanismo de Checkpointing Incremental (Exemplo da recuperação de Arquivos de Checkpoint) As FIGURAS 8, 9, 10 mostram um exemplo de recuperação de arquivos de checkpoint abordados pelo mecanismo de checkpointing incremental.

38 27 Servirá como exemplo os mesmo arquivos do exemplo de salvamento da seção anterior (seção 4.2.2). O estado da aplicação está espalhado em vários arquivos de checkpoint, havendo assim a necessidade percorrer os arquivos em busca dos objetos que contenham o seu último estado modificado. O processo de recuperação é feito do último arquivo de checkpoint para o primeiro. Através dos valores do estado de modificação de cada objeto armazenado no contêiner C (cabeçalho) dentro do contêiner principal, os objetos e seus estados são verificados. O Obj1 e Obj3 dentro do 3º arquivo de checkpoint (FIGURA 8) são verificados como sendo seus últimos estados modificados e salvos durante o processo de salvamento, os dois objetos são resgatados. Cabeçalho C Contêiner de Objetos C Obj1 3 3 Obj3 3º Arquivo de Checkpoint FIGURA 8 Estrutura da recuperação de arquivos de checkpoint pelo mecanismo de checkpointing incremental (3º Arquivo de Checkpoint) O próximo passo é percorrer os arquivos de checkpoint restantes em busca do último estado (mais atualizado) do Obj2. O 2º arquivo de checkpoint (FIGURA 9) contém somente o Obj3, este por sua vez já teve seu último estado obtido. Cabeçalho C Contêiner de Objetos C Obj3 2º Arquivo de Checkpoint FIGURA 9 Estrutura da recuperação de arquivos de checkpoint pelo mecanismo de checkpointing incremental (2º Arquivo de Checkpoint)