0007663521

UNIVERSIDADE FEDERAL DO RIO GRANDE DO SUL
INSTITUTO DE INFORMTICA
PROGRAMA DE PS-GRADUAO EM COMPUTAO
RAFAEL DAL ZOTTO
Proposta de Mecanismo de Checkpoint com

Armazenamento de Contexto em Memria
para Ambientes de Computao Voluntria
Dissertao apresentada como requisito parcial

para a obteno do grau de
Mestre em Cincia da Computao
Prof. Dr. Cludio Fernando Resin Geyer

Orientador
Porto Alegre, Setembro de 2010
CIP CATALOGAO NA PUBLICAO

Dal Zotto, Rafael
Proposta de Mecanismo de Checkpoint com Armazenamento
de Contexto em Memria para Ambientes de Computao Voluntria / Rafael Dal Zotto. Porto Alegre: PPGC da UFRGS, 2010.
134 f.: il.
Dissertao (mestrado) Universidade Federal do Rio Grande
do Sul. Programa de Ps-Graduao em Computao, Porto Alegre, BRRS, 2010. Orientador: Cludio Fernando Resin Geyer.
1. Computao voluntria. 2. Mecanismos para Checkpoint.
3. Alto Desempenho. 4. Prevalncia de Objetos. I. Geyer, Cludio
Fernando Resin. II. Ttulo.
UNIVERSIDADE FEDERAL DO RIO GRANDE DO SUL

Reitor: Prof. Carlos Alexandre Netto
Vice-Reitor: Prof. Rui Vicente Oppermann
Pr-Reitor de Ps-Graduao: Prof. Aldo Bolten Lucion
Diretor do Instituto de Informtica: Prof. Flvio Rech Wagner
Coordenador do PPGC: Profa. lvaro Freitas Moreira
Bibliotecria-chefe do Instituto de Informtica: Beatriz Regina Bastos Haro
An education isnt how much you have committed to memory, or even how
much you know. Its being able to differentiate between what you do know and
what you dont.
A NATOLE F RANCE
AGRADECIMENTOS
Nesta etapa final de minha escrita, gostaria de registrar minha gratido a todos aqueles
que participaram direta ou indiretamente dessa caminhada. Muito obrigado pelas conversas, apoio e incentivo oferecidos ao longo dessa jornada.
Foi Bertrand Russell quem disse que os nossos pais amam-nos porque somos seus
filhos, um fato inaltervel. Nos momentos de sucesso, isso pode parecer irrelevante, mas
nas ocasies de dificuldade, oferecem um consolo e uma segurana que no se encontram
em qualquer outro lugar. Muito obrigado aos meus pais, Livino e Vera, pelo exemplo,
educao, amor e apoio incondicional. Obrigado por serem esse porto seguro na minha
vida. Amo vocs.
minha amada namorada, Daiane. Obrigado por estar ao meu lado nos momentos em
que as dificuldades pareciam maiores do que realmente eram. Tuas palavras de incentivo,
teu abrao carinhoso e o teu lindo sorriso foram combustveis para que eu pudesse seguir
em frente. Esse o primeiro passo de uma longa caminhada que vamos trilhar juntos. Eu
te amo.
Agradeo ao meu orientador, Cludio Geyer, pela confiana depositada em mim. Sua
generosidade, comprometimento e disponibilidade foram decisivos para a produo desse
trabalho. Sem o seu direcionamento e suas sugestes precisas, essa pesquisa no teria sido
possvel. Muito obrigado por tudo.
Obrigado aos meus amigos, pelo incentivo durante a produo desse trabalho. Agradeo pelo interesse, pela ajuda e pelos questionamentos - eles foram fundamentais nesse
processo. Obrigado tambm por investirem seu tempo lendo, revisando e comentando
partes dessa dissertao. Obrigado.
Agradeo tambm Hewlett-Packard por incentivar os meus estudos. Obrigado pela
flexibilidade que permitiu que pudesse freqentar as aulas e participar das reunies do
grupo de pesquisa. Muito mais que uma oportunidade para crescimento profissional,
encontrei na HP um ambiente que permite o desenvolvimento pessoal.
SUMRIO
LISTA DE ABREVIATURAS E SIGLAS . . . . . . . . . . . . . . . . . . . .
LISTA DE FIGURAS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
11
LISTINGS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
12
RESUMO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
13
ABSTRACT
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
14
1 INTRODUO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.1
Objetivos e Contribuio . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.2
Estrutura do Texto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
15
16
17
2 COMPUTAO DISTRIBUDA . . . . . . . . . .
2.1
Computao em Cluster . . . . . . . . . . . . .
2.1.1
Cluster de Alta-Disponibilidade . . . . . . . . .
2.1.2
Cluster com Balanceamento de Carga . . . . .
2.1.3
Cluster de Alto Desempenho . . . . . . . . . .
2.1.4
Cluster com Web-Service . . . . . . . . . . . .
2.1.5
Cluster em Bases de Dados . . . . . . . . . . .
2.2
Peer to Peer Computing . . . . . . . . . . . . .
2.2.1
Objetivos de um sistema peer-to-peer . . . . .
2.3
Computao em Grade . . . . . . . . . . . . . .
2.4
Computao Voluntria . . . . . . . . . . . . .
2.4.1
Computao Voluntria como Metacomputao
2.4.2
Computao Global . . . . . . . . . . . . . . .
2.4.3
Frameworks para Computao Voluntria . . .
2.5
Consideraes Finais . . . . . . . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
19
19
21
21
22
22
22
22
24
24
26
26
27
29
30
IMPLEMENTAES DE MECANISMOS PARA CHECKPOINT E RESTART . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

3.1
Fundamentao Terica . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.2
Plataformas de Computao Voluntria . . . . . . . . . . . . . . . . . .
3.2.1
Condor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.2.2
BOINC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.2.3
XtremWeb . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.3
Implementaes em Nvel de Usurio . . . . . . . . . . . . . . . . . . . .
3.3.1
libckpt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
32
32
34
34
36
36
37
37
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
3.3.2
3.3.3
3.3.4
3.3.5
3.3.6
3.3.7
3.4
3.4.1
3.4.2
3.4.3
3.4.4
3.4.5
3.4.6
3.4.7
3.4.8
3.5
3.5.1
3.5.2
3.5.3
3.5.4
3.5.5
3.6
3.7
Libckp . . . . . . . . . . . . . . . . . . . . . . .
Libtckpt . . . . . . . . . . . . . . . . . . . . . .
Score . . . . . . . . . . . . . . . . . . . . . . . .
CoCheck . . . . . . . . . . . . . . . . . . . . . .
Esky . . . . . . . . . . . . . . . . . . . . . . . .
Dynamit . . . . . . . . . . . . . . . . . . . . . .
Implementaes em nvel de Sistema Operacional
VMADump . . . . . . . . . . . . . . . . . . . .
EPCKPT . . . . . . . . . . . . . . . . . . . . . .
CRAK . . . . . . . . . . . . . . . . . . . . . . .
Zap . . . . . . . . . . . . . . . . . . . . . . . .
BLCR . . . . . . . . . . . . . . . . . . . . . . .
UCLiK . . . . . . . . . . . . . . . . . . . . . . .
CHPOX . . . . . . . . . . . . . . . . . . . . . .
PsncR/C . . . . . . . . . . . . . . . . . . . . . .
Persistncia Ortogonal . . . . . . . . . . . . . . .
PS-Algol . . . . . . . . . . . . . . . . . . . . . .
Napier88 . . . . . . . . . . . . . . . . . . . . . .
Arjuna . . . . . . . . . . . . . . . . . . . . . . .
Persistent Java . . . . . . . . . . . . . . . . . . .
Outras Solues para Persistncia Ortogonal . . .
Outras Implementaes . . . . . . . . . . . . . .
Consideraes Finais . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
39
39
40
40
42
43
44
44
45
46
47
48
48
49
49
50
51
51
52
52
53
54
55
4 DISKLESS CHECKPOINT . . . . . . . . . . . . .
4.1
Fundamentao Terica . . . . . . . . . . . . . .
4.2
Neighbor-Based Checkpointing . . . . . . . . . .
4.2.1
Mirroring . . . . . . . . . . . . . . . . . . . . .
4.2.2
Ring Neighbor . . . . . . . . . . . . . . . . . . .
4.2.3
Pair Neighbor . . . . . . . . . . . . . . . . . . .
4.3
Parity-Based Checkpointing . . . . . . . . . . . .
4.3.1
Local Checkpointing . . . . . . . . . . . . . . .
4.3.2
Encoding Checkpointing . . . . . . . . . . . . .
4.3.3
Integrao de Local e Encoding Checkpointings .
4.4
Checksum-Based Checkpointing . . . . . . . . .
4.4.1
Esquema baseado em Soma de Verificao Bsico
4.4.2
Modelo de checksum de Uma Dimenso . . . . .
4.4.3
Modelo de checksum de Duas Dimenses . . . .
4.5
Checkpoint baseado em Weighted-Checksum . .
4.5.1
The Basic Weighted Checksum Scheme . . . . .
4.5.2
Two Dimensional Weighted Checksum Scheme .
4.6
Avaliao da Abordagem . . . . . . . . . . . . .
4.6.1
Vantagens . . . . . . . . . . . . . . . . . . . . .
4.6.2
Limitaes . . . . . . . . . . . . . . . . . . . . .
4.7
Consideraes Finais . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
56
56
59
59
60
61
61
62
63
65
65
66
66
67
67
68
70
70
70
71
71
5 MODELO PROPOSTO . . . . . . . . . . . .
5.1
Origem da Proposta . . . . . . . . . . . . .
5.1.1
Arquitetura Interna de uma MFP . . . . . .
5.1.2
MFPs em Computao Voluntria . . . . .
5.2
Viso Geral do Modelo . . . . . . . . . . . .
5.3
Prevalncia de Objetos para Persistncia . .
5.4
Organizao do Modelo . . . . . . . . . . .
5.4.1
Aplicaes . . . . . . . . . . . . . . . . . .
5.4.2
Implementando ITargetApplication
5.4.3
Utilizando a varivel StartupValue . . .
5.4.4
Estendendo ApplicationFacade . . .
5.4.5
Invocando a Prevalncia . . . . . . . . . . .
5.4.6
Exemplos de Modificaes . . . . . . . . .
5.5
Arquitetura do Mecanismo de Checkpoint .
5.5.1
ITargetApplication . . . . . . . . .
5.5.2
MainFacade . . . . . . . . . . . . . . . .
5.5.3
ApplicationJob . . . . . . . . . . . .
5.5.4
TargetApplicationDecorator . . .
5.5.5
PeriodicCheckpoint . . . . . . . . .
5.5.6
PrevalenceHelper . . . . . . . . . . .
5.5.7
ApplicationFacade . . . . . . . . . .
5.5.8
CheckpointTransaction . . . . . . .
5.5.9
CheckpointData . . . . . . . . . . . .
5.6
Checkpoint para XtremWeb . . . . . . . . .
5.6.1
Segurana e Execuo de Cdigo Nativo . .
5.6.2
Comunicao entre Workers e Servers . . .
5.6.3
Arquitetura . . . . . . . . . . . . . . . . .
5.7
Modificaes Propostas no Worker . . . . .
5.7.1
Activator Model . . . . . . . . . . . . . . .
5.7.2
Adaptando ThreadLaunch . . . . . . . .
5.8
Consideraes Finais . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
72
72
72
74
76
78
79
80
81
81
81
82
82
83
84
85
87
88
91
92
94
95
96
97
98
99
101
106
107
109
110
6 APLICAO DO MODELO E DESEMPENHO

6.1
Aplicao-alvo . . . . . . . . . . . . . . . . .
6.1.1
Cdigo Original . . . . . . . . . . . . . . . .
6.1.2
Modificaes . . . . . . . . . . . . . . . . .
6.2
Ambiente de Execuo . . . . . . . . . . . . .
6.3
Cenrios de Testes . . . . . . . . . . . . . . .
6.4
Resultados Obtidos . . . . . . . . . . . . . . .
6.4.1
Utilizao de memria heap . . . . . . . . .
6.4.2
Desempenho do garbage collector . . . . . .
6.4.3
Realizao de Snapshots . . . . . . . . . . .
6.4.4
Hotspots das Execues . . . . . . . . . . . .
6.5
Consideraes Finais . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
112
112
112
114
115
115
116
116
117
118
121
121
7 CONCLUSO . . . . . . . . . . . .
7.1
Reviso do Trabalho Desenvolvido
7.2
Contribuies . . . . . . . . . . . .
7.3
Trabalhos Futuros . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
123
124
125
125
REFERNCIAS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127
LISTA DE ABREVIATURAS E SIGLAS
API
Application Programming Interface
BOINC Berkeley Infrastructure for Network Computing

BoT
Bag-of-Tasks
BLCR
Berkeley Lab Checkpoint/Restart
CIL
Common Intermediate Language
CORBA Common Object Request Broker Architecture

CLR
Common Language Runtime
CPU
Central Processing Unit
GC
Global Computing
GPL
General Public License
HTTP
Hypertext Transfer Protocol
HPC
High-Performance Computing
IP
Internet Protocol
JNI
Java Native Interface
JVM
Java Virtual Machine
JRE
Java Runtime Environment
LAN
Local Area Network
LINQ
Language-Integrated Query
MFP
Multi Function Product/ Printer/ Peripheral
MHz
Megahertz
MPI
Message Passing Interface
MSIL
Microsoft Intermediate Language
MTBF Mean Time Between Failures

NAT
Network Address Translation
NVRAMNon-Volatile RAM
PDA
Personal Digital Assistant
P2P
Peer-to-Peer
PC
Personal Computer
PID
Process Identifier
PVM
Parallel Virtual Machine
PWD
Piecewise Deterministic Assumption
RAID
Redundant Array of Inexpensive Disk
RAM
Random Access Memory
RMI
Remote Method Invocation
RPC
Remote Procedure Call
SGI
Silicon Graphics, Inc.
SNMP Simple Network Management Protocol

SMP
Symmetric Multi-Processing
SSL
Secure Sockets Layer
TCP
Transmission Control Protocol
TCS
Terascale Computing System
UDP
User-defined protocol
XML
eXtensible Markup Language
XOR
Disjuno Exclusiva
XW
XtremWeb
LISTA DE FIGURAS
Figura 3.1:
Figura 3.2:
Figura 3.3:
Classificao das implementaes de mecanismos de checkpoint/restart 34

Caracterizao de um Estado Global . . . . . . . . . . . . . . . . . . 42
Limpando Canais de Comunicao . . . . . . . . . . . . . . . . . . 42
Figura 4.1:
Figura 4.2:
Figura 4.3:
Figura 4.4:
Figura 4.5:
Figura 4.6:
Figura 4.7:
Figura 4.8:
Estrutura de Diskless Checkpoint para grandes sistemas . . . . . . .

Esquemas de checkpoint baseado em vizinhos . . . . . . . . . . . .
Esquema de Paridade RAID nvel 5 . . . . . . . . . . . . . . . . .
Esquema baseado em checksum . . . . . . . . . . . . . . . . . . .
Esquema de Checksum de Uma Dimenso . . . . . . . . . . . . .
Esquema de Checksum de Duas Dimenses . . . . . . . . . . . . .
Modelo Bsico de Weighted Checksum . . . . . . . . . . . . . . .
Esquema de Checksum com Pessos Associados de Uma Dimenso .
.
.
.
.
.
.
.
.
57
60
63
66
67
68
68
70
Figura 5.1:
Figura 5.2:
Figura 5.3:
Figura 5.4:
Figura 5.5:
Figura 5.6:
Figura 5.7:
Figura 5.8:
Figura 5.9:
Figura 5.10:
Figura 5.11:
Figura 5.12:
Figura 5.13:
Figura 5.14:
Figura 5.15:
Figura 5.16:
Fluxo de utilizao diria de uma MFP . . . . . . . . . . . . . .

Fluxo bsico de execuo do Modelo . . . . . . . . . . . . . . .
Atividades do Modelo de Prevalncia . . . . . . . . . . . . . . .
Organizao dos Pacotes do Modelo . . . . . . . . . . . . . . . .
Modificaes necessrias na aplicao-alvo . . . . . . . . . . . .
Diagrama de Classes do Mecanismo de Checkpoint . . . . . . . .
Diagrama de Sequncia do Mecanismo de Checkpoint . . . . . .
Organizao das Threads do Modelo . . . . . . . . . . . . . . . .
Diagrama de Seqncia do mtodo RestoreInformation . .
Diagrama de Seqncia para o mtodo PrevalentExecution
Protocolo de Comunicao entre workers . . . . . . . . . . . . .
Arquitetura de sub-camadas da plataforma XtremWeb . . . . . .
Arquitetura de um Worker . . . . . . . . . . . . . . . . . . . . .
Arquitetura de um Servidor . . . . . . . . . . . . . . . . . . . .
Activator Model do XtremWeb . . . . . . . . . . . . . . . . . . .
Diagrama de Classes da ThreadLaunch . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
75
76
79
80
80
83
84
85
89
94
99
102
104
106
107
110
Figura 6.1:
Figura 6.2:
Figura 6.3:
Figura 6.4:
Figura 6.5:
rvore de Chamadas do checkpoint Peridico . . .

Tamanho Fsico do Snapshot em Disco . . . . . .
Tempo de execuo para recuperao de snapshots
Hotspots da Aplicao Original . . . . . . . . . .
Hotspots da Aplicao Modificada . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
119
120
120
121
122
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
LISTINGS
3.1
3.2
3.3
3.4
3.5
3.6
5.1
5.2
5.3
5.4
5.5
5.6
5.7
5.8
5.9
5.10
5.11
5.12
5.13
6.1
6.2
Funo setjmp . . . . . . . . . . . . . . . . . . . . . . . . .
Funo longjmp . . . . . . . . . . . . . . . . . . . . . . . .
Dump de memria do sleep . . . . . . . . . . . . . . . . . .
Persistncia ortogonal com PS-Algol . . . . . . . . . . . . .
Persistncia ortogonal utilizando DB4O . . . . . . . . . . .
Busca atravs de LINQ . . . . . . . . . . . . . . . . . . . .
Exemplo de Aplicao-Alvo Modificada . . . . . . . . . . .
Implementao da Interface ITargetApplication . . .
Cdigo da classe MainFacade . . . . . . . . . . . . . . .
Cdigo da classe ApplicationJob . . . . . . . . . . . .
Implementao do mtodo RunApplication . . . . . . .
Implementao do mtodo initializeStartupValue
Implementao do mtodo PositionateFilePointer
Cdigo da classe PeriodicCheckpoint . . . . . . . . .
Cdigo da classe PrevalenceHelper . . . . . . . . . .
Cdigo da classe ApplicationFacade . . . . . . . . .
Cdigo da classe CheckpointTransaction . . . . . .
Cdigo da classe CheckpointData . . . . . . . . . . . .
RFC 1759 - Printer MIB . . . . . . . . . . . . . . . . . . .
Aplicao N-Gramas Original . . . . . . . . . . . . . . . .
Aplicao N-Gramas Modificada . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 39
. 39
. 44
. 51
. 53
. 53
. 82
. 85
. 86
. 87
. 88
. 90
. 91
. 92
. 93
. 95
. 96
. 97
. 109
. 112
. 114
RESUMO
Computao voluntria um tipo de computao distribuda na qual o proprietrio do

computador cede parte dos seus recursos computacionais, tais como poder de processamento ou armazenamento, para a execuo de um ou mais projetos de pesquisa de seu
interesse. Na rea de processamento de alto desempenho, o modelo de computao voluntria desempenha um papel muito importante. Sistemas de computao voluntria de
larga escala provaram ser mecanismos eficientes para resoluo de problemas complexos.
Em tais sistemas, que so essencialmente centralizados, centenas ou milhares de computadores so organizados em rede para processar uma srie de tarefas, encaminhadas e
distribudas por um servidor central.
Nesse tipo de soluo, imprescindvel ter um mecanismo para a persistncia dos resultados intermedirios produzidos, de maneira peridica, para evitar a perda de informaes em caso de falhas. Esse mecanismo, chamado de checkpoint, tambm importante,
em ambientes de computao voluntria, para garantir que no momento em que o proprietrio do recurso retomar sua utilizao, os resultados intermedirios produzidos sejam
armazenados para uma posterior recuperao. Sem um mecanismo de checkpoint consistente, resultados produzidos pelos nodos de computao voluntria podem ser perdidos,
gerando um desperdcio do poder de computao.
A pesquisa contemplada nessa dissertao tem por objetivo propor um mecanismo
de checkpoint baseado no armazenamento do contexto de execuo, atravs da prevalncia de objetos. Essa abordagem proporciona a participao, em sistemas de computao
voluntria, de recursos com capacidades limitadas de processamento, memria e espao
em disco que possuam curtos, porm frequentes, perodos de inatividade. Dessa forma,
esses recursos podero realizar checkpoints rpidos e frequentes, produzindo resultados
efetivos.
Palavras-chave: Computao voluntria, Mecanismos para Checkpoint, Alto Desempenho, Prevalncia de Objetos.
A Proposal for a Checkpoint Mechanism based on Memory Execution-Context

Storage for Volunteer Computing Environments
ABSTRACT
Volunteer computing is a type of distributed computing in which resource owners

donate their computing resources, such as processing power and storage, to one or more
projects of interest. In the high-performance computing field, the volunteer computing
model has been playing an important role. On current volunteer computing systems,
which are essentially center-based, hundreds or thousands of computers are organized in
a network to process a series of tasks, originally distributed by a centralized server.
For this kind of environment, it is essential to have a mechanism to ensure that all intermediate produced results are stored, avoiding the loss of already processed data in case
of failures. This mechanism, known as checkpoint, is also important in volunteer computing environments to ensure that when the resource owner takes control of the activities, all
intermediate results are saved for later recovery. Without a consistent checkpoint mechanism, already produced data could be lost, leading to waste of computing power.
The research done on this dissertation aims mainly at introducing a checkpoint mechanism based on context execution storage, through object prevalence. On it, resources
which usually have limited processing power, memory and storage and with small but
frequent periods of inactivity could be allowed to join volunteer computing environments.
This is possible because they would be able to execute fast and frequent checkpoint operations in short period of times and therefore, be able to effectively produce results during
its inactivity periods.
Keywords: Volunteer computing, checkpoint, high-performance, object prevalence.
15
INTRODUO
O acesso a grandes quantidades de poder computacional tem sido, por diversas dcadas, um dos objetivos centrais de muitos cientistas da computao. Desde a dcada de
60, vises sobre componentes e ferramentas computacionais, sejam elas simples ou mais
complexas, tm guiado os esforos de usurios e engenheiros de sistemas (ORGANICK,
1972).
Na dcada de 70, iniciaram-se as idias cujos pensamentos centrais estavam focados
no objetivo de atingir esse poder computacional. A idia se apresentava atravs da coleo
e utilizao de diversos recursos pequenos e baratos em detrimento de poucos e caros
supercomputadores (STERLING et al., 1995). A partir desse pensamento, o interesse
em esquemas para o gerenciamento desses processadores distribudos se tornou cada vez
mais popular (THAIN et al., 2005).
Uma das abordagens para resoluo de problemas de maneira distribuda, atravs da
utilizao de recursos computacionais cedidos pelos proprietrios, atravs de uma soluo
de computao voluntria. O termo computao voluntria define um modelo computacional que provou sua capacidade de agrupar recursos distintos e oferecer ambientes para
processamento de alto desempenho (P.ANDERSON; FEDAK, 2006). A idia por trs da
computao voluntria, eliminar passos complexos de configurao de ambientes, fazendo com que a participao de qualquer usurio, independente do conhecimento tcnico
que possua, seja facilitada.
Como o prprio nome define, a disponibilidade de execuo em ambientes de computao voluntria existe apenas enquanto o usurio proprietrio est cedendo o seu recurso.
Isso significa que a execuo de um projeto, dentro desse tipo de ambiente, est sujeita a
inmeras interrupes que no podem ser determinadas com antecedncia. Dessa forma,
uma das preocupaes que devem ser endereadas nesse tipo de ambiente, o armazenamento dos resultados intermedirios produzidos, para que o processamento no seja
perdido por completo a cada interrupo de execuo. Para esse fim, as principais plataformas de computao voluntria oferecem mecanismos de checkpoint que podem ou no
serem utilizados, de acordo com as necessidades do projeto.
Dentro das principais plataformas para computao voluntria, o XtremWeb deve ser
mencionado. Trata-se de um software de cdigo aberto, desenvolvido pela universidade
de Paris Sd, para construir desktop grids atravs da utilizao de recursos disponveis
dos computadores pessoais. A plataforma XtremWeb permite transformar um conjunto
de recursos volteis, distribudos atravs de uma LAN ou mesmo da internet, em um ambiente integrado para execuo de aplicaes paralelas. Embora cumpra com os objetivos
de agregar recursos dispersos e transform-los em participantes de um projeto voluntrio, os resultados intermedirios produzidos dentro desse modelo no so armazenados.
Isso significa que sempre que o proprietrio de um recurso solicitar a retomada de execu-
16
o, toda e qualquer informao produzida perdida, gerando um desperdcio de poder

computacional.
Quando se fala em ambientes de computao voluntria, a imagem imediatamente associada a da utilizao de desktops pessoais que, quando fora de utilizao por parte
dos proprietrios, podem participar de maneira produtiva de um ambiente voluntrio. A
associao vlida e correta pois exatamente esse o tipo de recurso predominante no
ambiente voluntrio. Entretanto, a participao em um ambiente desse tipo no exclusiva de computadores pessoais, de modo que qualquer recurso com alguma capacidade
de processamento, pode participar. Tomando essa premissa como verdadeira, correto
afirmar que essa abrangncia inclui a possibilidade de, em teoria, utilizar recursos com
capacidades limitadas de processamento e memria como PDAs ou at mesmo impressoras.
exatamente no contexto de utilizar impressoras multifuncionais como recursos em
ambientes de computao voluntria, que a pesquisa apresentada nessa dissertao se insere. Uma impressora multifuncional pode ser definida como uma mquina que incorpora
a funcionalidade de mltiplos equipamentos em apenas um, oferecendo recursos e funcionalidades de impressora, scanner, foto-copiadora, fax e e-mail. Em termos de hardware,
as multifuncionais modernas apresentam configuraes semelhantes a desktops, o que
possibilitaria a sua utilizao em ambientes de computao voluntria. Entretanto, esse
tipo de recurso no utilizado principalmente pelo fato de apresentarem curtos, porm
freqentes, perodos de disponibilidade. Isso significa que, mesmo que uma multifuncional fosse includa em um ambiente de computao voluntria, ela dificilmente ficaria
disponvel tempo suficiente para processar resultados vlidos.
O primeiro aspecto para possibilitar a utilizao de multifuncionais em ambientes de
computao voluntria, disponibilizar um mecanismo de checkpoint rpido e eficiente.
A pesquisa realizada ao longo do mestrado e apresentada nessa dissertao, prope a
criao de um mecanismo de checkpoint que possa ser realizado de maneira freqente e
que no acarrete overhead em termos de tempo de execuo ao processamento normal do
recurso. Alm dessas premissas, a soluo proposta deve estar adaptada s limitaes, em
termos de memria e capacidade de armazenamento, do recurso ao qual estar vinculada.
O modelo criado a partir dessas restries faz uso do conceito de prevalncia de objetos e diskless checkpoint, combinado com persistncia eventual em disco, para armazenamento das informaes intermedirias produzidas. As aplicaes executadas dentro
do modelo de checkpoint proposto so encapsuladas dentro de transaes de prevalncia,
possibilitando que as informaes intermedirias produzidas possam ser armazenadas e,
em caso de falhas ou interrupes, recuperadas. Durante esse processo, a memria o
recurso utilizado para o armazenamento, para oferecer uma soluo mais robusta para armazenamento das informaes. Em contrapartida, o disco fsico pode ser eventualmente
utilizado para armazenar o estado geral da aplicao.
1.1
Objetivos e Contribuio
Envolvido nesse contexto, o objetivo principal dessa pesquisa consiste em propor um

mecanismo de checkpoint rpido em memria, atravs da utilizao de prevalncia de
objetos, para recursos com capacidades limitadas de memria e processamento. Tipicamente, dentro dessa classificao, esto includos recursos com curtos, porm freqentes,
perodos de disponibilidade para o processamento voluntrio.
Dessa forma, o mecanismo de checkpoint em questo foi projetado, implementado e
17
avaliado dentro de um contexto de execuo que simula as configuraes de hardware e

sistema operacional de uma multifuncional moderna. Alm do projeto e implementao
do mecanismo de checkpoint, foram realizados estudos detalhados da plataforma para
computao voluntria XtremWeb, para a qual foram projetados os ajustes necessrios
para a utilizao do modelo.
Como objeto final do estudo, tem-se um mecanismo de checkpoint implementado,
testado e avaliado em um ambiente de execuo muito prximo do qual se prope ser
aplicado. Alm disso, tem-se o projeto para utilizao desse novo mecanismo de checkpoint dentro da plataforma XtremWeb, que por padro no possui nenhum mecanismo
para armazenamento de resultados intermedirios produzidos. Isso significa que essa
proposta permitir a realizao de checkpoints de maneira rpida e freqente ao worker
do XtremWeb.
Como resultado da possibilidade de se realizar operaes de checkpoint freqentes e
de maneira rpida, recursos computacionais que at ento eram descartados em ambientes
de computao voluntria, passam a ser opes vlidas. Dessa forma, o ambiente voluntrio poder contar com mais recursos para a realizao do processamento das atividades,
aumentando a capacidade total de processamento.
1.2
Estrutura do Texto
Para oferecer um entendimento geral e proporcionar uma melhor leitura, esta dissertao est organizada em mais cinco captulos, que oferecem uma viso geral dos conceitos
envolvidos no estudo, chegando aos detalhes de projeto e implementao do modelo proposto. O captulo 2 apresenta uma viso geral sobre solues de computao distribuda.
Nesse captulo, so apresentados e definidos conceitos relacionados com computao em
cluster, peer-to-peer e computao em grade, chegando no objetivo principal do estudo,
que a computao voluntria. dentro do modelo de computao voluntria que a
proposta para checkpoint com prevalncia de objetos se aplica.
Em seguida, o captulo 3 apresenta um estudo sobre solues e implementaes de
mecanismos de checkpoint e restart. Esse captulo apresenta uma fundamentao terica
sobre mecanismos de checkpoint e restart e classifica as implementaes em quatro grandes grupos: solues para plataformas de computao voluntria, implementaes em
nvel de usurio, implementaes em nvel de sistema operacional e persistncia ortogonal. Para cada um desses grupos, as principais solues foram estudadas e apresentadas.
O captulo 4 apresenta o estado da arte sobre diskless checkpoint. Nesse captulo so
apresentados os principais modelos de soluo para checkpoint em memria: neighorbased, parity-based, checksum-based e weighted-checksum. Ao final deste captulo, so
apresentadas algumas vantagens e limitaes do modelo, quando comparado ao checkpoint tradicional em disco.
O captulo 5 entra em detalhes de projeto e implementao do modelo de checkpoint
proposto nessa dissertao. nesse captulo onde a origem dessa proposta surgiu e tambm os conceitos de prevalncia de objetos so estabelecidos. Tambm mostrado o
projeto e implementao do modelo proposto, bem como as adaptaes necessrias ao
worker do XtremWeb.
Por fim, o captulo 6 utiliza uma aplicao real para validar o conceito proposto. Nesse
captulo, uma aplicao real adaptada e utilizada dentro do conceito de checkpoint com
prevalncia de objetos e os resultados de desempenho so coletados e apresentados.
nesse captulo que o desempenho, em termos de performance, medido para a aplicao
18
modificada e executada dentro do modelo de checkpoint proposto e comparado com a

execuo da aplicao original. Para que os resultados avaliados se aproximassem do
tipo de recurso para o qual o modelo de checkpoint foi proposto, os testes descritos nesse
captulo foram executados em um ambiente que simula uma impressora multifuncional.
No captulo 7, so apresentadas as concluses do estudo realizado nessa dissertao,
alm de indicaes das contribuies obtidas. Alm disso, esse captulo apresenta indicativos para trabalhos futuros, onde o modelo pode ser ampliado e adaptado para atender
outros problemas.
19
COMPUTAO DISTRIBUDA
O acesso a grandes quantidades de poder computacional tem sido, por diversas dcadas, um dos objetivos centrais de muitos cientistas da computao. Desde a dcada de
60, vises sobre componentes e ferramentas computacionais, sejam elas simples ou mais
complexas, tm guiado os esforos de usurios e engenheiros de sistemas (ORGANICK,
1972).
Na dcada de 70 surgiram as idias cujos pensamentos centrais estavam focados no
objetivo de atingir esse poder computacional. A idia se apresentava atravs da coleo
e utilizao de diversos recursos pequenos e baratos em detrimento de poucos e caros
supercomputadores (STERLING et al., 1995). A partir desse pensamento, o interesse
em esquemas para o gerenciamento desses processadores distribudos se tornou cada vez
mais popular (THAIN et al., 2005).
Quando a utilizao de mltiplos computadores para resolver um nico problema
computacional se tornou possvel, o foco passou para o estudo e pesquisa na utilizao
mxima dos ciclos de CPU desses equipamentos.
Para as diversas formas de organizao em rede para resoluo de problemas de maneira distribuda, atribui-se o nome de computao distribuda. Esse captulo apresenta
alguns dos principais conceitos relacionados computao distribuda: Cluster Computing e suas classificaes, peer-to-peer, computao em grade e computao voluntria.
2.1
Computao em Cluster
De acordo com (TOTH, 2004), um cluster pode ser inicialmente definido como um
grupo de computadores que trabalham em conjunto de uma maneira fortemente acoplada
que, em alguns aspectos, pode ser visto e entendido como um nico computador. Os
componentes de um cluster so ligados entre si, tipicamente, por uma rede local de alta
velocidade (TOTH, 2004).
Dentre as diversas aplicaes que utilizam cluster, cabe destaque s solues nos ramos de simulaes, biotecnologia, mercado de finanas, geologia, data mining, processamento digital e mesmo para computao de jogos pela internet (TOTH, 2004).
De acordo com (BAKER et al., 1999) um cluster em sua formatao mais simples
pode ser estabelecido atravs dos computadores interconectados em uma rede interna de
uma empresa ou universidade. Essa formatao definida por Buyya et al em (BAKER
et al., 1999) como um workstation cluster, que sinnimo para um cluster. Em (BAKER
et al., 1999), o artigo estabelece que alm da conexo de hardwares, um cluster tambm
inclui a utilizao de um middleware que permite aos computadores participantes do cluster atuarem como nodos de um sistema distribudo, atuando sobre aplicaes que foram
designadas para rodarem neles.
20
Um sistema de cluster, segundo (TOTH, 2004), pode ter seus nodos alocados de
acordo com duas abordagens simples: esttica ou dinmica. Na alocao esttica, os
nodos computacionais do cluster so organizados de maneira prxima, tendo como objetivo a execuo de uma tarefa complexa qualquer, j conhecida. Atravs da alocao
dinmica, a arquitetura de alocao dos nodos do cluster somente conhecida momentos
antes da tarefa de processamento ser iniciada.
Segundo definido por (BARAK et al., 1999), (BAKER et al., 1999) e (TOTH, 2004),
um cluster composto por todos os componentes que podem ser encontrados em uma
LAN de computadores e workstations: computadores individuais com seus processadores, memria e discos; cartes de rede; cabeamentos; bibliotecas de software e sistemas;
sistemas operacionais; middlewares e quaisquer outras ferramentas ou utilitrios.
De acordo com (BARAK et al., 1999) Computing Clusters so compostos por colees de workstations sem compartilhamento de recursos (share-nothing workstations) e
servidores, com velocidades e quantidade de memria semelhantes. Um cluster definido como heterogneo, para as situaes em que os nodos que o compem so formados
por diferentes tipos de computadores enquanto que um cluster homogneo composto
por nodos de um nico tipo de computadores (TOTH, 2004). Na maioria das configuraes, os computing clusters so organizados para que suportem mltiplos usurios, em
ambientes que sejam propcios para compartilhamento de tempo (BARAK et al., 1999).
Em computing clusters os usurios dos recursos so responsveis por alocar os processos
desejados nos nodos do cluster e manter e gerenciar tanto os recursos quanto os nodos
durante a execuo. De acordo com (BARAK et al., 1999), mesmo que todos os nodos do
cluster rodem o mesmo sistema operacional, a cooperao entre os nodos relativamente
limitada pois a maioria dos servios oferecidos pelo sistema operacional em questo so
limitados e confinados a cada nodo.
Solues de cluster podem ter diferentes tamanhos e, por isso, uma das maiores vantagens de solues que sigam essa abordagem a escalabilidade (RECHERCHE NUCLAIRE, 2009), pois o crescimento de um cluster est vinculado to somente a adio
de novos computadores (nodos) a ele. Essa abordagem, no entanto, possui limites pois
de alguma forma os computadores desse cluster precisam se comunicar entre si e isso
comea a trazer problemas, quando se fala de cluster com muitos computadores (RECHERCHE NUCLAIRE, 2009).
O artigo (JATIT, 2009) define algumas caractersticas bsicas que configuram e definem um Cluster Computing, as quais so transcritas abaixo e complementadas com as
caractersticas estabelecidas em (AHMAD, 2000):
Sistemas fortemente acoplados, o que resulta em uma arquitetura fortemente centralizada;
Configura (e deve ser visto como) uma imagem nica de sistema;
Gerenciamento de trabalhos centralizado;
Sistema de escalonamento centralizado;
Deve prover escalabilidade, permitindo ao sistema utilizar mais ou menos recursos,
de acordo com a necessidade;
O sistema operacional utilizado e o mecanismo de comunicao, por serem nicos
a todo o cluster,
21
devem ser suficientemente eficientes para remover ou mitigar gargalos de performance.

De acordo com (JATIT, 2009), possvel afirmar que quando dois ou mais computadores so utilizados em conjunto para a resoluo de um problema, a arquitetura formada a partir da juno destes pode ser chamada de computer cluster. Por essa definio,
entende-se que Cluster Computing a ao de executar algum problema em um cluster
(JATIT, 2009). Em (RECHERCHE NUCLAIRE, 2009) e (JATIT, 2009), feita uma
definio em relao abrangncia de um cluster. De acordo com os autores, um cluster
est contido em um local ou um complexo definido e fixo, como, por exemplo, a rede de
uma universidade ou computadores de uma empresa.
Diferente da estrutura simples que se encontra na rede de uma universidade ou na rede
de uma empresa, onde cada computador administrado e gerenciado individualmente por
uma pessoa, em um cluster todos os nodos so administrados, tipicamente, por uma nica
pessoa. Ao contrrio de executar tarefas especficas e particulares de um usurio, os nodos
de um cluster trabalham em conjunto para realizar tarefas de computao intensa, procurando resolver tarefas que no podem ser executadas em mquinas individuais, devido ao
baixo poder de processamento ou devido a questes de tempo (TOTH, 2004).
Mesmo que todos os nodos de cluster precisem ser acionados para resolver um determinado problema, o poder de um cluster est justamente na habilidade de cada nodo
trabalhar em conjunto para resolver um pedao especfico do problema, resultando em
um ganho de performance que pode ser comparado a um supercomputador. Ao contrrio
dos caros supercomputadores, um cluster pode ser formado por dezenas de centenas de
computadores pequenos e baratos, configurando uma soluo barata quando comparada
aos supercomputadores (TOTH, 2004).
De acordo com (TOTH, 2004) e baseado em (STEEN, 2007), os clusters podem ser
categorizados em:
2.1.1
Cluster de Alta-Disponibilidade
O objetivo principal dessa arquitetura de clusters oferecer um sistema de alta disponibilidade, tolerante a falhas. A melhoria de disponibilidade desse tipo de cluster obtida
atravs do estabelecimento de nodos redundantes para cada servio de processamento que
est sendo executado. Por padro, determina-se a existncia de 2 nodos para cada servio
- que, por conseqncia estabelece o limite de tolerncia existente (se os dois nodos falharem, o cluster deixa de ser de alta-disponibilidade). Existem diversas implementaes
comerciais de clusters HA no mercado, para diversos sistemas operacionais. Um exemplo
o Linux-HA, que uma soluo open source para cluster de alta disponibilidade para o
sistema operacional Linux.
2.1.2
Cluster com Balanceamento de Carga
O objetivo desse tipo de arquitetura de cluster dividir a carga de trabalho computacional entre os nodos, objetivando ganhos de performance e reduo do tempo de processamento, alm de uma melhor diviso na carga de trabalho para cada nodo. Esse tipo
de arquitetura de cluster tambm chamado de server-farm (TOTH, 2004). Existem no
mercado diversas solues de software que contemplam esse tipo de arquitetura, como
por exemplo Sun Grid Engine, Moab Cluster e Maui Cluster Scheduler.
22
2.1.3
Cluster de Alto Desempenho
O objetivo desse tipo de arquitetura de cluster dividir a tarefa computacional em

diversas sub-tarefas e encaminhar cada uma delas para os diversos nodos do cluster. As
aplicaes executadas em clusters HPC devem ser planejadas para que, quando divididas, minimizem o custo de comunicao entre os nodos pois, tipicamente, o resultado
do processamento de um nodo importante para as atividades de outros nodos. comum
encontrar clusters HPC construdos sob linux, que utilizam a biblioteca MPI para as atividades de comunicao.
2.1.4
Cluster com Web-Service
Essa classificao de clusters diz respeito organizao sistemtica que feita para
permitir que a descoberta e utilizao de web services possa ser feita atravs de mtodos de minerao de textos, anlises lingsticas e tcnicas estatsticas combinadas (LIO,
2005).
2.1.5
Cluster em Bases de Dados
De acordo com (DOHERTY, 2003), Database clusters podem ser definidos como
uma classificao de clusters que compartilham o acesso, manipulao e gerenciamento
de informaes armazenadas em bases de dados, tendo como objetivo principal a melhoria
de performance.
Conforme definido em (CHANDRASEKARAN; KEHOE, 2002), os clusters de bases
de dados podem ser divididos em duas categorias:
Shared Nothing clusters: nesse tipo de arquitetura, os arquivos da base de dados
so distribudos atravs das diversas instncias de bases de dados que so executadas nos nodos dos clusters. Cada instncia tem total controle sobre um conjunto
especfico de dados e todo e qualquer acesso sobre estes, deve ser feito atravs do
nodo proprietrio (CHANDRASEKARAN; KEHOE, 2002);
Shared Disk clusters: nessa arquitetura compartilhada, os arquivos da base de dados
so logicamente distribudos atravs dos nodos. Atravs dessa abordagem, todos os
nodos do cluster tm acesso a todos os dados (DOHERTY, 2003). O acesso a disco
compartilhado, segundo (CHANDRASEKARAN; KEHOE, 2002), feito atravs
de acesso direto a hardware ou atravs de uma camada de abstrao no sistema
operacional, que oferece uma viso simples de todas as instncias, de todos os
nodos.
2.2
Peer to Peer Computing
O termo peer-to-peer se refere a uma classe de sistemas e aplicaes que empregam

recursos distribudos para executar uma determinada funo ou atividade de uma maneira
descentralizada (MILOJICIC et al., 2003).
Enquanto um peer um computador que se comporta como um cliente em um modelo cliente/servidor, ele tambm possui uma camada adicional de software que permite,
no modelo P2P, que se comporte para determinadas funes como um servidor. Os peers
podem ento responder s requisies de outros peers, como se fossem servidores respondendo a chamadas dos clientes, na arquitetura cliente servidor tradicional. O escopo das
23
chamadas e das respostas e a maneira como so executadas, so de domnio especfico da

aplicao (BARKAI, 2000).
Segundo (MILOJICIC et al., 2003), muitos especialistas na rea acreditam que no
existem muitas novidades na arquitetura P2P e que existe muita confuso e indefinio
em relao ao que ela se difere no modelo tradicional de cliente-servidor distribudo. Em
(BARKAI, 2000), esse questionamento totalmente respondido quando o autor define
que as solues P2P se apresentam como uma alternativa complementar arquitetura
tradicional de cliente-servidor. Segundo (BARKAI, 2000), P2P oferece um modelo computacional ortogonal em relao ao modelo cliente-servidor tradicional, permitindo que
os dois modelos possam coexistir, se cruzarem e se complementarem.
No modelo cliente-servidor tradicional, o cliente faz uma requisio ao servidor. O
servidor, tipicamente um recurso dedicado, responde requisio e atua, de acordo com
o que foi solicitado pelo cliente. Na abordagem das arquiteturas P2P, cada computador
participante, chamado de peer, funciona como um cliente com uma camada de funcionalidades de servidor. Isso permite ao peer, atuar tanto como cliente - fazendo requisies como servidor, respondendo requisies de outros clientes, dentro do contexto de uma
aplicao P2P (BARKAI, 2000).
As aplicaes P2P podem ter funes de armazenamento, processamento de informaes, troca de mensagens, segurana e, principalmente, compartilhamento de arquivos.
Para todas essas funes, as solues feitas com uma arquitetura P2P permitem que os
peers troquem informaes diretamente entre si, sem a necessidade da utilizao de um
ou mais servidores especficos, centralizados.
Como mencionado anteriormente, um peer pode iniciar requisies e pode tambm
responder a requisies enviadas rede por outros peers. Essa habilidade de executar
trocas de informaes diretamente com outros usurios (peers) faz com que no seja mais
necessria a dependncia de um servidor central (BARKAI, 2000). Isso permite um maior
grau de autonomia e controle, por parte dos usurios, sob os servios que esto disponveis
para atualizao.
Como citado em (BARKAI, 2000) um dos maiores benefcios das arquiteturas P2P
a possibilidade de organizao dos peers em comunidades. Isso permite aos usurios
mecanismos para que se organizem em grupos ad hoc que podem, de maneira segura
e eficiente, compartilhar recursos e colaborar entre si para resoluo de um problema
comum. Alm desse benefcio (BARKAI, 2000) e (MILOJICIC et al., 2003) citam como
recursos e facilidades de uma arquitetura P2P:
possibilidade de agregar novos recursos atravs de um custo de interoperabilidade
baixo;
custo baixo em relao ao compartilhamento de informao, atravs da utilizao
de infra-estruturas j existentes;
permite anonimato e privacidade, atravs da incorporao desses cuidados nos algoritmos e programas P2P.
Entretanto, (MILOJICIC et al., 2003) destaca que sistemas P2P despertam nos usurios algumas preocupaes no que diz respeito a segurana das informaes. Porm, em
contraponto, o mesmo autor cita que como trata-se de uma tecnologia em pleno desenvolvimento, esforos esto sendo feitos para mitigar esse problema.
As arquiteturas P2P podem, em algumas situaes, fazer uso de servidores centralizados. Em relao a essa abordagem, alguns especialistas em P2P traam uma clara
24
distino de termos, classificando os sistemas em "Sistemas P2P Puros"e "Sistemas P2P

Hbridos". O termo "puro"denota os modelos onde todos os computadores participantes
so peers. Nos sistemas ditos puros, no existe um servidor responsvel por coordenar,
controlar ou gerenciar as trocas de dados e informaes entre os peers. De outro lado, o
termo hbrido define justamente as arquiteturas P2P que fazem uso desses servidores centralizados, para a execuo de algumas atividades. O grau de envolvimento desse servidor
centralizado varia de acordo com a aplicao. Em (BARKAI, 2000) usado o exemplo
do Napster, onde requerido ao usurio que se conecte a um servidor de controle, para
ento obter acesso aos recursos, propriamente ditos.
2.2.1
Objetivos de um sistema peer-to-peer
Como todo e qualquer sistema computacional, os sistemas P2P tm alguns objetivos

principais, para garantir que a soluo satisfaz as necessidades dos usurios. Escolher a
arquitetura P2P para implementao de algum recurso, na maioria das vezes, guiada por
alguns dos objetivos (BARKAI, 2000):
Reduo do custo de compartilhamento: sistemas centralizados que possuem muitos clientes, tipicamente, possuem um custo alto para manter recursos compartilhados;
Aumento da disponibilidade: sem a necessidade de um recurso central dedicado
(que pode falhar) a responsabilidade se divide em inmeros peers que, individualmente podem falhar sem comprometer a disponibilidade;
Aumento da escalabilidade: a adio de novos nodos a rede P2P descomplicada e
fcil, fazendo com que novos participantes sejam agregados e possam rapidamente
participar de maneira ativa;
Privacidade: um usurio pode querer que nenhum servio saiba de sua participao
ou envolvimento;
Dinamismo: sistemas P2P assumem que o ambiente altamente dinmico. Isso
significa estar preparado para que um grande nmero de recursos entre e saia de
maneira dinmica e indeterminada;
Agregao de Recursos: por no ter um servio centralizado para controle, agregar
novos componentes ou recursos uma tarefa fcil em ambientes P2P;
Autonomia: os usurios no precisam confiar em um nico servio centralizado.
A informao pode estar disponvel em outros peers ou at mesmo para consulta e
manipulao local;
2.3
Computao em Grade
De acordo com (STEEN, 2007), as grades computacionais podem ser classificadas

como uma caracterizao de cluster, pois se assemelham em diversos aspectos: assim
como os clusters, as grades computacionais fazem uso de diversos computadores (recursos) conectados de alguma maneira, organizados para resolver um problema de tamanho
considervel (TOTH, 2004).
25
O termo Grid computing foi criado na segunda metade da dcada de 90 pelo dr. Ian
Foster (ECONOMIST, 2008). A idia do professor Foster era fornecer recursos computacionais dentro da mesma lgica em que se fornece energia eltrica: qualquer pessoa
deveria ter acesso a recursos computacionais para resolver um problema sempre que necessrio (FOSTER et al., 2001). No artigo "Anatomia de um Grid", os professores Foster,
Kesselman e Teucke definiram o "problema de grid"como um "compartilhamento de recursos flexvel, seguro, coordenado entre indivduos, instituies e recursos"(FOSTER
et al., 2001). A posteriori, Foster estabeleceu trs caractersticas bsicas, que definem as
caractersticas de uma grade e dos problemas que nelas so executados:
1. Um grid utiliza "interfaces e protocolos genricos, padres e abertos"(FOSTER,
2002);
2. Os recursos utilizados no esto sob o controle de uma nica entidade ou instituio;
3. Um grid gera, como resultado, servios no triviais com qualidade"(FOSTER, 2002).
Baseado nas concluses de (JATIT, 2009) e de acordo com as caractersticas estabelecidas por Foster, pode-se estabelecer que, ao contrrio de um cluster tpico, as solues
em grade so descentralizadas, diversificadas e dinmicas, alm de possurem um gerenciamento de trabalhos e escalonamento distribudo. Entretanto, o termo grid computing
muitas vezes utilizado para descrever muitos tipos de arquiteturas que no esto de
acordo com as definies de Foster et al, causando dvidas sobre a real definio do
termo (FOSTER et al., 2001).
As definies muitas vezes no so suficientes para esclarecer todas as dvidas e confuses que surgem a partir da tentativa de diferenciao dos termos Cluster Computing
e Desktop Computing. De acordo com (TOTH, 2004) e (CROGRID, 2009), algumas
caractersticas podem ser apontadas como fatores de diferenciao:
Grids so totalmente heterogneos, enquanto que clusters, em sua grande maioria,
so homogneos;
As grades computacionais podem fazer uso do tempo ocioso dos computadores que
a compem, permitindo que exista um processamento "extra-grade"desses recursos;
nos clusters, o trabalho dos nodos totalmente dedicado a uma nica atividade e
nada mais;
As grades computacionais podem ser compostas por computadores localizados ao
redor do mundo, atravs da internet, enquanto que os clusters, usualmente so montados dentro de uma nica localidade ou complexo;
No existe confiana entre os recursos que compem uma grade computacional, ao
contrrio do que existe nos clusters.
Em (TOTH, 2004), o autor destaca que as grades computacionais so otimizadas para
executarem tarefas de processamento que consistem em diversos jobs ou pacotes de trabalho independentes, onde no necessrio existir troca de dados e de mensagens entre
os pacotes de trabalho durante o processamento das atividades. As grades so responsveis por gerenciar a alocao dos pacotes de trabalho nas estaes de trabalho que iro
resolver o problema, independente do comportamento dos demais recursos da grade computacional (TOTH, 2004).
26
2.4
Computao Voluntria
O termo computao voluntria define um modelo computacional emergente que se

adapta facilmente ao modelo de processamento de work-pool. Esse conceito provou sua
capacidade de agrupar recursos e oferecer ambientes para processamento de alto desempenho em projetos de sucesso, como por exemplo SETI@Home, Folding@Home
entre outros (P.ANDERSON; FEDAK, 2006). A ttulo de exemplificao, o projeto
SETI@Home agrega, ao redor do mundo mais de 1,5 milho de desktops que, de maneira
voluntria, cedem suas capacidades de processamento para utilizao cientfica (ANDERSON et al., 2002) e (PRESS, 2003). Esse grande nmero de dispositivos agregados levam
a uma capacidade de processamento de aproximadamente 250 TeraFlops, de acordo com
estatstica disponvel 1 . Esse poder de processamento pode ser comparvel ao IBM Blue
Gene, que oferece uma velocidade de 360 TeraFlops.
2.4.1
Computao Voluntria como Metacomputao
Em (SARMENTA, 2001), o autor define computao voluntria como uma forma de

metacomputao, que maximiza o modo como os usurios podem fazer com que suas mquinas faam parte de um metacomputador. O termo metacomputao tipicamente denota
uma organizao estrutural que configura um computador virtual, consistido de computadores individuais localizados de maneira geograficamente distribuda (possivelmente),
interconectados atravs de uma rede de alta velocidade. Metacomputao , portanto, motivada pela real necessidade de acessar recursos que freqentemente no esto localizados
em um nico sistema computacional (FOSTER; KESSELMAN, 1997).
Metacomputao permite que aplicaes de larga escala utilizem recursos computacionais de alta performance de uma maneira desacoplada (KESSELMAN et al., 1998).
Esse tipo de sistema esconde toda a complexidade de gerenciamento do usurio, permitindo que este permanea focado em seu negcio, em sua cincia e menos preocupado
com os detalhes de implementao e configurao do ambiente. O objetivo principal de
utilizar um sistema de metacomputao permitir que recursos que tipicamente estariam
indisponveis, estejam disponveis permitindo que sejam utilizados pelos usurios, para o
processamento de uma determinada tarefa. Essa utilizao, por sua vez, esconde a complexidade do gerenciamento dos recursos do usurio, facilitando as atividades e fazendo
com que ele foque os seus esforos nica e exclusivamente nos seus objetivos cientficos
(CRONK et al., 2000).
Atravs da utilizao dos conceitos de metacomputao, possvel que problemas
muito grandes ou complexos de serem executados em sistemas de alta performance tradicionais, sejam executados com sucesso (CRONK et al., 2000) nesse ambiente de execuo. Os sistemas de metacomputao existentes atualmente assumem sua implementao
baseada no conceito de NOW. Essa arquitetura permite s pessoas conectarem os seus recursos em uma rede de processamento maior, objetivando a participao em uma soluo
paralela distribuda ampla. Essa abordagem evita a necessidade de investimentos em um
supercomputador (FIELDS, 2008), tornando a soluo efetiva e financeiramente vivel.
Enquanto outras formas de metacomputao, como grid computing, buscam fazer com
que o uso do poder de processamento de computadores em uma rede seja facilitado, o
processo de configurao desses computadores no algo trivial. Atualmente, a maioria
desses projetos foca em disponibilizar computadores ou recursos de uma rede para utilizao de outros. De modo que essas mquinas, por muitas vezes no estarem em mos de
1
Estatstica disponvel em http://boincstats.com/stats, acessado em Fev. 2009
27
especialistas, fazer um processo de instalao simples no uma prioridade. justamente

essa complexidade de instalao e configurao que faz com que usurios comuns fiquem
sem participar desses sistemas.
A idia por trs da computao voluntria eliminar esses passos complexos de configurao, fazendo com que a participao de qualquer usurio, independente do conhecimento tcnico que possua, seja facilitada. Isso acarreta como resultado o fato de que
todos, mesmo usurios casuais de sistemas de informtica sem muito conhecimento tcnico, possam participar de sistemas desse tipo (SARMENTA, 2001). Por permitir que
usurios casuais possam contribuir com o tempo ocioso de suas mquinas, o uso de ambientes de computao voluntria torna possvel juntar o processamento de centenas ou
mesmo milhares de computadores, objetivando o desenvolvimento de um determinado
projeto de interesse (SARMENTA, 2001).
2.4.2
Computao Global
Os conceitos de Computao Global e Computao Voluntria so semelhantes e,

de certa forma complementares. De acordo com (NERI et al., 2001), a idia central de
Computao Global otimizar o mximo possvel o uso dos computadores que podem
estar largamente distribudos ao redor do mundo, conectados atravs da internet.
Essa otimizao e utilizao de recursos largamente distribudos poderia ser utilizada
para executar uma aplicao distribuda de grande porte qualquer. Ainda baseado em
(NERI et al., 2001), todo o poder de processamento a ser utilizado cedido por computadores voluntrios, que estariam dispostos a oferecer uma fatia do tempo de processamento
ocioso em prol da execuo de parte dessa grande aplicao distribuda. Atravs da definio oferecida possvel compreender que os conceitos se assemelham bastante. O termo
global pode, ento, ser entendido como uma utilizao, em termos globais, de computadores que cooperam entre si de maneira voluntria, interconectados por uma rede de
computadores, como a internet, por exemplo.
2.4.2.1
Problemas Relacionados Computao Global
Quando se fala em projetos de aplicaes construdos sob o conceito de computao global atravs da utilizao de recursos voluntrios, importante enderear algumas
preocupaes tipicamente relacionadas. Em (NERI et al., 2001), o autor enumera essas
preocupaes que as aplicaes devem ter:
1. Escalabilidade: deve escalar para centenas de milhares de nodos, com um aumento
de performance correspondente;
2. Heterogeneidade: deve ser heterogneo em relao a hardware, sistema operacional
e softwares bsicos;
3. Disponibilidade: o proprietrio do recurso quem determina a poltica de uso do
mesmo. E o sistema global em questo, deve garantir e obedecer toda e qualquer
restrio imposta;
4. Tolerncia a falhas: a MTBF de uma mquina conectada na internet de aproximadamente 13 horas. Dessa forma, o sistema global deve ser tolerante a esse constante
nmero de falhas e, mesmo assim, manter um nvel de performance aceitvel;
5. Segurana: todos os nodos participantes devem estar protegidos de execues de
cdigos maliciosos ou manipulaes equivocadas;
28
6. Dinamicidade: o sistema deve ser suficientemente dinmico para acomodar um

nmero freqentemente varivel de recursos disponveis, bem como possveis mudanas freqentes em relao a velocidade e largura de banda das conexes;
7. Usabilidade: deve ser fcil para utilizao e o deploy da aplicao ou projeto deve
ser descomplicado.
2.4.2.2
Exemplos de Projetos
Existem inmeros exemplos de aplicaes criadas utilizando frameworks para computao voluntria, que podem ser citados como exemplos de solues que se enquadram
no conceito de Global Computing. Em (FEDAK et al., 2001) o autor cita algumas, como:
2.4.2.2.1
SETI@Home
Trata-se de um dos projetos mais populares desenvolvidos atravs da utilizao da

plataforma BOINC. O projeto SETI@home tem por objetivo analisar os sinais de rdio
freqncia coletados do espao, para busca de padres que possam identificar a existncia
de vida extra-terrestre.
Nro. Ativo de usurios: 199,000
Sistemas Operacionais Suportados:Linux, Mac OS X, Solaris e Windows
2.4.2.2.2
GIMPS
Esse projeto de computao voluntria visa concentrar esforos na busca de nmeros

Mersennes que sejam primos. Em matemtica, pode ser definido como um nmero primo,
definido atravs da seguinte forma:
Mn = 2n 1
Esse projeto ento visa encontrar nmeros n, que sejam primos. Para esse objetivo, a
soluo fazer uso do conceito de computao voluntria.
Nro. Ativo de usurios: desconhecido
Sistemas Operacionais Suportados: Linux, FreeBSD, OS/2 e Windows (Verses "extraoficiais"de outros Sistemas Operacionais).
2.4.2.2.3
Einstein@Home
Projeto, construdo na plataforma BOINC, que objetiva fracionar as ondas gravitacionais em pequenas pores e compar-las individualmente, contra modelos pr-definidos.
Sistemas Operacionais Suportados: Linux, Mac OS X, Solaris e Windows.
2.4.2.2.4
LHC@Home
Projeto criado sob a plataforma BOINC, que simula o movimento de partculas dentro
do LHC - acelerador de partculas do CERN.
Sistemas Operacionais Suportados: Linux, Mac OS X, Solaris e Windows
2.4.2.2.5
Folding@Home
Um dos projetos mais antigos para simulao de protenas. Os projetos atuais visam
o estudo de doenas como Alzheimer, Cncer, Hintington e Parkinson entre outras.
29

Sistemas Operacionais Suportados: Linux, Mac OS X, Windows, PLAYSTATION 3.
2.4.2.2.6
MalariaControl.net
Projeto que foca o esforo nos estudos sobre a Malria na frica. O estudo feito
levando em conta diversos fatores biolgicos e sociais e os resultados ajudam os cientistas
na criao de vacinas e similares.
Nro. Ativo de usurios: 8.000
Sistemas Operacionais Suportados: Linux, Mac OS X e Windows.
2.4.2.2.7
Rosetta@Home
Utiliza a plataforma BOINC para auxiliar no entendimento de doenas como HIV,

Malaria, Cncer atravs de simulaes em 3D de protenas.
Sistemas Operacionais Suportados: Linux, Mac OS X e Windows
2.4.2.2.8
Xgrid@Stanford
Projeto de pesquisa para, conforme definio fornecida pela universidade de Stanford,

modelar mudanas do receptor beta 2. O projeto desenvolvido sob o XGrid e focado
para computadores Macintosh apenas.
Nro. Ativo de usurios: 500
Sistemas Operacionais Suportados: Mac OS X
2.4.2.2.9
ClimatePrediction.net
Criado sob a plataforma BOINC, esse projeto tem como objetivo executar projees
climticas atravs de diferentes variveis para verificar e medir a evoluo do aquecimento
global.
Sistemas Operacionais Suportados: Linux, Mac OS X e Windows
Alm destes projetos mencionados, existem diversos outros que tambm utilizam frameworks e middlewares para computao voluntria, como por exemplo Predictor@Home,
Evolution@Home, SIMAP, EON Project, Drug Design and Optimization Lab, AfricanClimate@Home, FightAIDS@Home, Help Conquer Cancer, Human Proteome Folding project Phase 2, Seasonal Attribution, ABC@home, Pi Segment, Seventeen or Bust, DIMES,
The Lattice Project, SoundExpert e yoyo@home entre outros.
2.4.3
Frameworks para Computao Voluntria
Existem diversos frameworks de computao voluntria, existentes no mercado, disponveis para utilizao. Dentre os frameworks, os mais citados e utilizados so o Bayanihan, BOINC e XtremWeb, todos desenvolvidos em universidades e, em sua grande
maioria, com cdigo aberto. Entretanto, existem tambm solues proprietrias, com cdigo fechado. As sees seguintes apresentam alguns dos frameworks para computao
voluntria disponveis.
2.4.3.1
Bayanihan
Bayanihan foi desenvolvido pelo pesquisador Luis Sarmenta, como parte da sua tese
de doutorado. Embora no seja mais utilizado formalmente, esse framework foi o pri-
30
meiro sistema genrico de computao voluntria baseado em Java, para solues web e,
segundo o autor, foi a primeira soluo de computao voluntria para internet disponibilizada (SARMENTA, 2001). Bayanihan um framework que permite que os usurios
compartilhem seus computadores como recursos voluntrios sem riscos de segurana e
sem a necessidade de instalao de nenhum software extra. Para participar como recurso
voluntrio, bastava aos usurios visitar a pgina do projeto na internet e, de maneira automtica, o browser realizava o download e executava uma applet Java com a aplicao
ou projeto (SARMENTA, 2001).
2.4.3.2
BOINC
o principal e mais utilizado framework para construo de projetos de computao

voluntria. BOINC foi desenvolvido na Universidade da Califrnia, no laboratrio de
cincias espaciais, em Berkeley (ANDERSON, 2004). BOINC permite a uma pessoa com
um computador simples criar um projeto de computao voluntria sem a necessidade de
escrever cdigo para o cliente e o servidor. O framework prov os scripts e ferramentas
necessrias para configurar todo o ambiente, exceto o cdigo de processamento, que
a tarefa que deve ser codificada pelo criador do projeto. O framework permite ainda
que os participantes (voluntrios) realizem ajustes customizados nas configuraes, que
afeta como o BOINC ser executado em suas mquinas, garantindo total personalizao
(STAFF, 2008).
2.4.3.3
Xgrid
Xgrid uma soluo para computao voluntria desenvolvida pela Apple, focada
especificamente para as arquiteturas Mac OS. De acordo com os autores do framework,
projetos que utilizem Xgrid geram uma soluo escalvel e de alta disponibilidade.
2.4.3.4
GridMP
Grid MP uma soluo de middleware para computao voluntria comercial, desenvolvida pela empresa United Devices. De acordo com (DEVICES, 2008) a soluo
GridMP utilizada com sucesso em projetos como grid.org, World Community Grid, Cell
Computing e Hikari Grid. Grid MP oferece mecanismos para escalonamento de tarefas
com priorizao, restries de segurana, excluso de aplicaes, deteco de atividades.
GridMP pode ser utilizado para o gerenciamento de recursos como computadores pessoais, servidores ou nodos dedicados de clusters; esses recursos podem ser organizados em
grupos organizacionais para segurana e controles administrativos (ASHOK, 2007).
2.4.3.5
Outros Frameworks
Em complemento aos frameworks que esto disponveis livremente para uso, existem
outros softwares e componentes que podem ser utilizados para criar projetos de computao voluntria personalizados. Existem tambm empresas como United Devices e
Entropia, que produzem componentes de software que podem ser usados em solues de
computao voluntria.
2.5
Consideraes Finais
Esse captulo apresentou alguns dos principais conceitos relacionados computao

distribuda. O primeiro conceito detalhado foi o de computao em cluster, onde as suas
31
classificaes foram apresentadas e definidas. O segundo conceito apresentado foi o de

peer-to-peer, onde os objetivos desse tipo de sistema foram detalhados. Alm disso,
tambm foi introduzido o termo computao em grade.
O termo computao voluntria, por sua vez, foi apresentado em mais detalhes para
que fosse possvel permitir o entendimento do conceito que o define. Isso foi feito pois o
trabalho proposto nessa dissertao diretamente aplicado a plataformas de computao
voluntria. O modelo de checkpoint com prevalncia de objetos que detalhado atravs
da pesquisa descrita nessa dissertao, tem como objetivo principal, ser executado em
plataformas de computao voluntria.
32
3 IMPLEMENTAES DE MECANISMOS PARA CHECKPOINT E RESTART
Dentro da rea de checkpointing, diversos trabalhos foram propostos e inmeros prottipos de solues implementados. Essas solues apresentam diferentes tcnicas para
oferecer a persistncia da execuo e dos dados dos processos e aplicaes, permitindo a
recuperao das informaes e o reincio da execuo em um estado consistente.
Esse amplo conjunto de solues pode ser dividido em basicamente trs categorias,
de acordo com a arquitetura da soluo e o nvel de invaso ou modificao que ele gera,
dentro do sistema ou aplicao ao qual est acoplado. A primeira categoria contempla as
solues onde o checkpoint realizado pela prpria aplicao, diretamente no cdigo. A
segunda, contempla os mecanismos onde o checkpoint realizado atravs de bibliotecas
ligadas aplicao. A terceira categoria faz referncia aos mecanismos para checkpoint
que so implementados diretamente no sistema operacional. Podemos ainda adicionar
uma quarta categoria que so os mecanismos de checkpoint implementados dentro dos
middlewares para computao voluntria, que podem utilizar quaisquer das trs categorias
mencionadas acima.
Neste captulo, sero apresentados os detalhes sobre os mecanismos de checkpoint
disponveis nas principais plataformas de computao voluntria, alm de detalhar algumas solues de checkpoint que so implementadas atravs da utilizao de bibliotecas
extras, que so acopladas aplicao. Tambm nesse captulo, so apresentadas algumas
implementaes que utilizam recursos do sistema operacional ou que sejam implementadas diretamente como mdulos do mesmo. Dentro desse mesmo aspecto, tambm so
apresentados mecanismos de checkpoint que so implementados atravs de modificaes
nas mquinas virtuais.
3.1
Fundamentao Terica
Para as categorias de implementaes de checkpoints mencionadas anteriormente, so

apresentados em (ROMAN, 2002), alguns aspectos positivos e tambm algumas limitaes.
Mecanismos de checkpoint implementados diretamente nas aplicaes se apresentam
como as solues com a maior eficincia, pois o programador da aplicao conhece exatamente os melhores pontos ou situaes, bem como as estruturas de dados utilizadas, onde
a execuo de uma operao de checkpoint necessria. O fato de conhecer exatamente
os dados que precisam ser persistidos e os que podem ser descartados, alm de conhecer exatamente o momento mais adequado para a realizao de checkpoints a principal
vantagem dessa abordagem, porm, pode se tornar um grande obstculo. Isso porque
33
a aplicao em que se deseja implementar o mecanismo de checkpoint pode no ter o

cdigo fonte acessvel, ou pode pertencer a terceiros tendo o cdigo fonte inacessvel.
Outra desvantagem que o modelo de checkpoint realizado diretamente dentro da aplicao apresenta, segundo (ROMAN, 2002), que as aplicaes podem oferecer restries
severas em relao ao momento em que a operao de checkpoint pode ser realizada.
comum que operaes de checkpoint s possam ser realizadas depois um determinado
perodo de tempo, o que pode tornar invivel a persistncia adequada das informaes,
pois o tempo transcorrido pode ser muito grande, causando uma grande demora entre os
perodos de checkpoint.
Implementaes de mecanismos de checkpoint realizados atravs de bibliotecas extras
endeream solues para algumas das deficincias existentes na abordagem de checkpoint
em nvel de aplicao. A principal delas que a utilizao de bibliotecas pode fazer com
que no sejam necessrias alteraes diretas no cdigo da aplicao, o que pode reduzir o
acoplamento da soluo.
A utilizao de bibliotecas para realizao de checkpoint tambm oferece uma soluo nica para a execuo da operao de restart. Enquanto que solues de checkpoint
realizadas na aplicao podem ter diversos mecanismos diferentes para a recuperao das
informaes, essa implementao em nvel de biblioteca unifica o processo.
Entretanto, a bibliografia apresenta uma limitao da abordagem de checkpoint atravs
da utilizao de bibliotecas: o fato de utilizar uma biblioteca extra pode impor restries
em relao a quais chamadas de sistema a aplicao pode utilizar. Isso significa que a
utilizao de bibliotecas limita o nmero e a variedade de chamadas de sistema que podem ser realizadas pela aplicao. Segundo (ROMAN, 2002), essa limitao faz com
que todas as formas de comunicao entre processos (por exemplo pipes), sejam geralmente proibidas, o que traz como resultado a impossibilidade de realizar checkpoint em
aplicaes paralelas.
A terceira categoria de mecanismos de checkpoint diz respeito a solues implementadas em nvel de sistema operacional, atravs, por exemplo, de modificaes realizadas
diretamente no kernel do mesmo. Trata-se de outra abordagem eficiente, j que a grande
maioria das estruturas de dados so acessveis ao kernel do sistema operacional, se reduzem a mnimas as restries em relao ao escopo das aplicaes. Mecanismos de checkpoint implementados na camada de sistema operacional tipicamente permitem que as
informaes relevantes das aplicaes sejam persistidas a qualquer momento. Entretanto,
a complexidade envolvida nessa abordagem faz com que os mecanismos de checkpoint e
restart estejam disponveis apenas para alguns poucos sistemas.
Com base em (SANCHO et al., 2005) os mecanismos de checkpoint so classificados
tendo como base trs dimenses: contexto, agente e implementao. Contexto referese ao local onde o checkpoint ser realizado, em termos de quem o responsvel pela
execuo: sistema operacional ou usurio. Dependendo do contexto a ser utilizado,
existem agentes especficos para a realizao do checkpoint: programador, compilador,
LD_PRELOAD, sistema operacional ou hardware. A ltima camada de classificao baseada no agente que implementa o checkpoint e responsvel por definir, propriamente
dito, o modelo de implementao a ser seguido: API, signal handlers de usurio ou kernel, chamadas diretas de sistema ou threads de kernel.
A figura 3.1 ilustra a classificao descrita acima. As implementaes de mecanismos
de checkpoint feitas em nvel de usurio podem ser programadas no cdigo-fonte da aplicao diretamente pelo programador da aplicao ou inseridas automaticamente por um
pr-compilador. Nessas abordagens, via de regra, uma biblioteca especfica para check-
34
Figura 3.1: Classificao das implementaes de mecanismos de checkpoint/restart

point utilizada para fornecer as primitivas necessrias, eliminando a necessidade de
diretamente programar essas chamadas. Uma alternativa modificao de cdigo-fonte
da aplicao a utilizao de chamadas s primitivas de checkpoint atravs de handlers
de sinais, em nvel de usurio. Outras implementaes fazem uso da varivel de ambiente
LD_PRELOAD, instalando handlers de sinais e realizando o carregamento das bibliotecas
necessrias para a realizao de checkpoints sem a necessidade de recompilar ou linkar
a aplicao. Como alternativa s implementaes realizadas na camada de usurio, diversos mecanismos para checkpoint so implementados em nvel de sistema operacional
ou at mesmo diretamente em hardware. Quando trabalha-se diretamente na camada de
sistema operacional, existem vrias tcnicas que possibilitam a realizao de checkpoints:
handlers de sinais ligados ao kernel do sistema operacional, implementao de chamadas
de sistemas ou utilizao de threads do kernel (SANCHO et al., 2005).
3.2
Plataformas de Computao Voluntria
Mecanismos para realizao de checkpoints tambm podem ser aplicados a plataformas de computao voluntria, onde tambm so importantes, mas nem sempre necessrios. A necessidade da existncia ou no de um mecanismo de checkpoint est diretamente
vinculada com a aplicao que est sendo executada.
Abaixo so apresentadas as solues para realizao de checkpoint para as principais
plataformas de computao voluntria.
3.2.1
Condor
O mecanismo de checkpoint existente na plataforma Condor oferece ao escalonador

a liberdade para realizar operaes de escalonamento reaproveitando informaes j produzidas. Com essa idia, caso o escalonador decida no mais executar uma determinada
atividade em uma mquina especfica, o checkpoint das informaes intermedirias produzidas at o momento realizado, e o job pode ser realocado em outro recurso, retomando as atividades do ponto onde foi anteriormente interrompido. Adicionalmente ao
mecanismo de checkpoint preemptivo descrito, a plataforma oferece tambm a possibilidade para execuo de checkpoints peridicos, provendo um mecanismo para tolerncia a
falhas. Nessa segunda abordagem, caso ocorra alguma interrupo no servio, a execuo
35
pode ser retomada a partir do ltimo checkpoint realizado (TEAM, 2009).

Segundo (TEAM, 2009), Condor oferece servios para realizao de checkpoint em
jobs de processos simples, para plataformas Unix. Para utilizar esses servios, necessrio que o usurio da plataforma realize o link do programa com a biblioteca especfica da
plataforma, libcondorsyscall.a, atravs do compilador especfico da plataforma.
Isso significa que para ser possvel a utilizao do recurso de checkpoint, o usurio precisa
ter acesso aos objetos do programa (para efetuar o link) ou diretamente ao cdigo fonte.
Os servios de checkpoint so opcionais. Dessa forma, o mecanismo pode ser utilizado de acordo com a convenincia do job em questo. Isso significa que algumas aplicaes executadas dentro do ambiente Condor podem fazer uso do mecanismo, enquanto
outras no. Entretanto, ambas classes de aplicao so executadas de maneira normal e
indiferenciada na plataforma Condor, fazendo uso dos mesmos recursos e funcionalidades
oferecidos pela plataforma.
O processo de checkpoint implementado atravs de chamadas biblioteca especfica
da plataforma, atravs de signal handlers (TEAM, 2009). Quando Condor envia um sinal
de checkpoint para um processo que esteja linkado com essa biblioteca, o signal handler
em questo serializado para um arquivo fsico em disco ou para um socket da rede,
onde as informaes referentes ao estado do processo so armazenadas. De acordo com
(TEAM, 2009), esse estado armazenado contempla as informaes da pilha e tambm
segmentos de dados, cdigos existentes em bibliotecas compartilhadas e dados mapeados
dentro do espao de endereo do processo. Alm disso, (TEAM, 2009) tambm cita
que o estado dos arquivos abertos alm de sinais pendentes e signal handlers existentes
so serializados no arquivo de checkpoint produzido. Quando a operao de restart
realizada, o processo l essas informaes do disco e recupera as informaes. Nesse
momento, o recurso est novamente em um estado consistente, onde a execuo pode ser
retomada.
A abordagem de execuo de checkpoints peridicos pode ser configurada atravs da
expresso PERIODIC_CHECKPOINT, configurada para cada pool Condor. Essa expresso permite definir o perodo (uma hora, duas horas, trs horas,...) em que o checkpoint
deva ser executado. Quando o momento de realizao de um checkpoint peridico ocorrer, o processamento suspende momentaneamente a execuo do job, realiza a operao
de checkpoint, produzindo o arquivo em disco, e imediatamente retoma a execuo normal do processo. Condor tambm oferece a possibilidade de induzir a realizao imediata
de um checkpoint, atravs da chamada do comando condor_ckpt. Esse comando permite que um usurio solicite ao Condor que uma execuo de checkpoint peridico seja
imediatamente realizada (TEAM, 2009).
O ambiente Condor faz uso de uma abordagem de commit para manuteno das informaes de checkpoint. Isso significa que um arquivo de checkpoint somente removido
do sistema quando comprovada a existncia de uma verso mais atual, sem falhas. Dessa
forma, caso a realizao de um checkpoint seja interrompida no meio, de modo que se
apresente como uma verso inconsistente, as informaes so imediatamente descartadas
e o checkpoint anterior permanece em disco e ser utilizado em caso de falhas.
Em (TEAM, 2009), os autores citam que a realizao de um checkpoint pode ser
momentaneamente postergada, caso o momento no seja adequado para a interrupo
da execuo. Isso se aplica, por exemplo, no caso do processo estar realizando uma
comunicao com outro processo no momento em que o checkpoint deva ser realizado.
Em um cenrio como esse, a realizao do checkpoint postergada at o trmino da
comunicao, quando ento o processo pode ser suspenso e o checkpoint realizado.
36
O comportamento padro observado pelo Condor o de criar o arquivo de checkpoint

em disco, de maneira local, na mquina onde o job foi submetido. Entretanto, (TEAM,
2009) cita que um pool do Condor pode ser configurado para utilizar um ou mais servidores dedicados para armazenar as informaes de checkpoint. Quando um servidor
configurado para ser utilizado como repositrio de checkpoints, os jobs executados escrevem e buscam os arquivos de checkpoint nessa mquina dedicada, no utilizando mais o
disco local para isso.
3.2.2
BOINC
BOINC, acrnimo para Berkeley Open Infrastucture For Network Computing , como
visto anteriormente, uma plataforma destinada a implementao de sistemas de computao voluntria, funcionando atravs de uma grade computacional de dimenses mundiais,
fazendo uso de computao oportunista. Dentre os diversos recursos oferecidos por essa
plataforma, um deles a possibilidade da realizao de operaes de checkpoint e restart
(ANDERSON et al., 2006).
Segundo (ANDERSON et al., 2006), esse recurso permite que as aplicaes executadas dentro do ambiente do BOINC possam ser interrompidas e posteriormente recuperadas. Por ser um sistema de computao oportunista, fundamental que mecanismos como
esse estejam disponveis para permitir a retomada de execuo do projeto, nos momentos
em que o recurso esteja disponvel, sem a necessidade de reiniciar as atividades do incio,
sempre.
Dentro das configuraes de usurios do BOINC, possvel configurar um intervalo
mnimo de ciclos de disco para realizao de checkpoints. Isso significa que possvel
configurar um nmero de intervalos de ciclos de disco mnimo que deva ser observado
para que operaes de checkpoint sejam realizadas. Isso especialmente interessante para
ambientes executados em notebooks, por exemplo, pois esse tipo de recurso, em perodos
de inatividade, diminui a velocidade dos seus discos para garantir uma maior economia de
energia. Dessa forma, a plataforma BOINC permite a realizao freqente de checkpoints,
entretanto, o perodo mnimo de ciclos de disco sempre observado (ANDERSON et al.,
2006).
A API do BOINC tambm oferece recursos para marcao de sesses crticas. Algumas aplicaes possuem determinados estados de execuo que precisam ser mantidos de
maneira ntegra, e a realizao de um checkpoint em um ponto intermedirio pode gerar
um arquivo de checkpoint inconsistente e, portanto, indesejado. Para mitigar esse problema, o BOINC oferece em sua API a possibilidade de chamadas para funo para marcao de regies crticas de execuo. A funo bool time_to_checkpoint();
deve ser chamada, de maneira explcita, quando a aplicao estiver em um estado consistente, onde a realizao de um checkpoint se apresenta como desejvel. permitido que
essa chamada seja realizada de maneira muito freqente. Entretanto, apesar de ser explicitamente ativada pelo usurio programador da aplicao, a restrio do nmero mnimo de
ciclos de disco sempre observado e tem prioridade sob a chamada. Se a restrio de ciclos for aceita, a aplicao pode ento chamar a funo checkpoint_completed();,
indicando que o arquivo de checkpoint foi gerado (ANDERSON et al., 2006).
3.2.3
XtremWeb
A plataforma XtremWeb, segundo (CAPPELLO et al., 2005) e (PRUITT, 2002), no

possui nenhum mecanismo de checkpoint implementado. Isso significa dizer que em caso
de falhas ou interrupes na execuo de uma aplicao, a atividade deve ser retomada
37
sempre do incio, independente do estado em que foi interrompida ou do percentual de

evoluo da tarefa, antes de ser paralizada. Isso pode ser visto como uma limitao da
plataforma, se comparada com outros ambientes de computao oportunstica, pois os
resultados intermedirios produzidos nunca so considerados ou armazenados em caso
de interrupes.
Entretanto, apesar de no oferecer um mecanismo de checkpoint para ser utilizado, a
plataforma disponibiliza diversos mecanismos para tolerncia a falhas, por parte dos diversos componentes da plataforma. O objetivo principal desses mecanismos possibilitar
que a execuo do sistema possa ser retomada, depois de qualquer falha. No so, entretanto, utilizadas tcnicas de redundncia, embora seja planejado para verses futuras.
Isso significa que em caso de ocorrncia de falhas nos recursos, a execuo da aplicao
retomada, mas o job reiniciado sempre desde o incio, fazendo com que as informaes
intermedirias produzidas at o momento, sejam perdidas (HIGAKI et al., 1997; PRUITT,
2002).
3.3
Implementaes em Nvel de Usurio
Os mecanismos de checkpoint que fazem uso de bibliotecas extras ou extenses de bibliotecas apresentam-se como uma abordagem interessante para realizao de operaes
de checkpoint. Mecanismos dessa abordagem so caracterizados por estarem desacoplados do cdigo da aplicao, oferecendo facilidades e melhorias para a manuteno da
aplicao.
Essa seo apresenta algumas das principais solues de mecanismos de checkpoint
implementados atravs da utilizao de bibliotecas.
3.3.1
libckpt
Libckpt uma das primeiras implementaes de bibliotecas para checkpoint disponibilizadas para UNIX (ROMAN, 2002). De acordo com (PLANK et al., 1995), Libckpt
oferece uma proposta para habilitar mecanismos de tolerncia a falhas para aplicaes
de longa durao. Libckpt implementa grande parte das otimizaes e melhorias propostas em termos de desempenho em operaes de checkpoint, focando especialmente na
reduo do tamanho dos arquivos gerados pelas operaes de checkpoint.
Essa biblioteca permite a sua utilizao de duas maneiras distintas. A primeira realizada de maneira totalmente transparente ao programador, ou seja, as operaes de checkpoint so realizadas nos momentos necessrios, sem o conhecimento do programador, de
maneira automtica. Outra abordagem atravs da utilizao de diretivas de programao, introduzidas diretamente na aplicao, pelo programador. Nessa segunda abordagem,
o programador pode, se desejvel, introduzir diretivas de programao dentro do cdigo
da aplicao, habilitando, dessa forma, a realizao das operaes de checkpoint nos momentos em que forem consideradas mais importantes (PLANK et al., 1995).
Apesar da implementao do mecanismo de checkpoint estar contido em uma biblioteca extra, para a sua utilizao necessrio uma modificao mnima na aplicao em
que se deseja habilitar recursos de checkpoint. Para habilitar a utilizao de checkpoints,
a aplicao deve ser modificada, renomeando a rotina principal do programa. A alterao consiste, basicamente em converter o nome do procedimento inicial escrito em C de
main() para ckpt_target(). Essa modificao permite que o libckpt possa recuperar o controle da execuo da aplicao desde o seu incio. Caso a aplicao seja escrita
em FORTRAN, o mdulo principal PROGRAM deve ser renomeado para SUBROUTINE
38
ckpt_target(). Com essa alterao, a aplicao deve obrigatoriamente ser recompilada e, de maneira esttica, linkada com a biblioteca libckpt (PLANK et al., 1995).
A realizao de checkpoints transparentes atravs da biblioteca libckpt feita de maneira incremental (ELNOZAHY et al., 1992; FELDMAN; BROWN, 1989; WILSON;
MOHER, 1989). Isso feito atravs de chamadas de sistema mprotect para manter o
controle sobre as pginas de memria modificadas dentro de um determinado endereo de
memria. Essas pginas modificadas so ento marcadas como sujas e, no momento em
que uma operao de checkpoint realizada, somente as pginas marcadas nesse estado
so escritas dentro do arquivo de checkpoint. Isso faz com que o tamanho do arquivo de
checkpoint seja reduzido, alm de melhorar o desempenho, em relao ao tempo de escrita
do arquivo. Apesar dessa vantagem, a utilizao de checkpoints incrementais faz com que
arquivos de checkpoints antigos no possam ser descartados, pois as informaes e dados
sensveis para a recuperao da aplicao podem estar distribudos em diversos arquivos
de checkpoint. Para mitigar esse problema, a biblioteca libckpt oferece um programa
utilitrio chamado ckpt_coa que pode ser utilizado para concatenar diversos arquivos
incrementais de checkpoint em apenas um arquivo (PLANK et al., 1995).
A utilizao de checkpoint incremental, apesar de benfica, ainda assim faz com que a
execuo do checkpoint seja sequencial. Para viabilizar isso, a biblioteca libckpt oferece a
possibilidade de realizar operaes de checkpoint de maneira assncrona: no momento em
que se torna necessria a execuo de um checkpoint, um processo filho criado atravs
da utilizao de uma chamada de sistema fork() (LON et al., 1993; PAN; LINTON,
1989). Esse novo processo criado ento responsvel por realizar o checkpoint em disco
(PLANK et al., 1995).
As abordagens de checkpoint apresentadas, bem como as suas otimizaes para ganhos de desempenho nos tempos de criao e persistncia de informaes mantm a transparncia na execuo atravs de tcnicas ou recursos que no so tipicamente visveis para
as aplicaes: signal handlers, criao de processos filhos e utilizao direta de pginas
de memria. Como abordagem para melhorar ainda mais o desempenho da biblioteca,
apresentado em (PLANK et al., 1995) duas abordagens para realizao de checkpoints direcionados atravs da ao direta do usurio: excluso de memria e checkpoint sncrono.
Como visto, o procedimento de checkpoint incremental utilizado pela biblioteca libckpt
utiliza as pginas de memria marcadas como sujas para serem persistidas nas informaes de checkpoint. Entretanto, mesmo as pginas de memria marcadas como sujas podem conter informaes que no sejam relevantes ou importantes para serem persistidas,
nem mesmo necessrias durante o processo de recuperao do estado. Para possibilitar
uma maior flexibilidade em termos dos contedos que so contemplados nos arquivos de
checkpoints, a biblioteca libckpt permite que o programador, de maneira explcita, determine possveis segmentos de memria que no so importantes e que no precisam,
necessariamente, serem persistidos durante a execuo do checkpoint. A utilizao desse
recurso pode reduzir drasticamente o tamanho do arquivo final gerado, porm deve ser utilizado com absoluto cuidado posto que a excluso errada de determinados segmentos de
memria pode causar a execuo de checkpoints inconsistentes, fazendo que a aplicao
no seja apta a recuperar seu estado consistente (PLANK et al., 1995).
Outra opo para realizao de checkpoint abordagem sncrona. Checkpoint sncrono permite que o programador da aplicao introduza diretivas de cdigo diretamente
no fonte da aplicao, indicando os pontos em que a realizao de checkpoints mais interessante. Essa abordagem chamada de sncrona pois no realizada pelas interrupes
de tempo normal do libckpt e sim por diretivas especficas. Entretanto, a utilizao muito
39
frequente das chamadas para realizao de checkpoints pode causar perdas significativas
de desempenho. Para mitigar esse problema que pode ser gerado atravs da frequente
chamada de checkpoints, libckpt permite estabelecer intervalos mnimos que devem ser
respeitados entre execues de checkpoints (PLANK et al., 1995).
3.3.2
Libckp
Segundo (ROMAN, 2002), libckp uma implementao para checkpoint/restart implementada atravs da utilizao de bibliotecas extras projetada especificamente para tolerncia a falhas. Libckp, quando comparado com as demais implementaes, apresenta
como diferencial o tratamento dado manipulao de arquivos. Em (WANG et al., 1995),
o autor cita que o libckp trata o contedo dos arquivos abertos e manipulados pela aplicao no momento do checkpoint como sendo parte do estado do processo.
A biblioteca libckp faz cpias dos arquivos abertos e tambm cpias de possveis
arquivos removidos atravs da chamada de sistema unlink(). Ainda de acordo com
(WANG et al., 1995), libckp disponibiliza mecanismos para a realizao de chamadas,
similares a setjmp e longjmp que permitem aplicao iniciar, de maneira explcita,
o inicio de uma operao de checkpoint ou realizar uma operao de rollback, retornando
para um estado previamente armazenado atravs de um checkpoint.
Objetivando detalhar, a funo setjmp() da API C, C + + salva no envbuf1 as
informaes de sistema que estejam na pilha, para posteriormente serem utilizadas pelas
chamadas longjmp(). A funo, tipicamente, tem a assinatura apresentada na listagem:
Listing 3.1: Funo setjmp
# include <csetjmp >
i n t setjmp ( jmp_buf envbuf ) ;
Em contrapartida, a funo longjmp() faz com que a execuo de um determinado

programa seja iniciada a partir do ponto onde a ltima chamada para a funo setjmp()
tenha sido realizada. Essa funo tem a assinatura mostrada abaixo:
Listing 3.2: Funo longjmp
# include <csetjmp >
v o i d longjmp ( jmp_buf envbuf , i n t status ) ;
3.3.3
Libtckpt
Dieter e Lumpp apresentam em (DIETER et al., 2001) uma extenso do conceito

apresentado em Libckpt para lidar com processos multi-threads destinado a permitir a
execuo de checkpoints em threads POSIX, chamado libtckpt. A soluo em questo
adiciona aplicao uma nova thread que ser responsvel pela execuo dos checkpoints.
Durante as execues de checkpoint e restart, essa thread adicionada utilizada para
sincronizar as demais threads envolvidas na aplicao e executar as eventuais chamadas
de callbacks do usurio. As eventuais chamadas de callback podem ser instaladas pelos
usurios da aplicao em trs momentos distintos:
1. Antes do checkpoint ser executado;
1
envbuf representa o espao de memria existente no ambiente de execuo, destinado a armazenar

informaes temporrias.
40
2. Aps o checkpoint ser finalizado;

3. Aps o restart ser realizado.
Libtckpt garante a consistncia das informaes pois todas as threads relacionadas
com a execuo da aplicao so suspensas antes do incio das atividades de checkpoint.
O estado das threads obtido atravs do envio de um sinal POSIX para cada uma das
threads envolvidas, e o checkpoint propriamente dito tambm ocorre atravs de sinais
do mesmo tipo. Uma limitao do modelo o fato de que o libtckpt no capaz de
processar sinais pendentes enviados se a thread em questo estiver bloqueada por um
mutex ou por semforos. Para contornar essa limitao, a biblioteca libtckpt precisa,
antes de iniciar o processo de checkpoint, desbloquear todas as threads causando um
sincronismo no objeto, para que ento, cada thread possa receber e lidar com os sinais
de checkpoint de maneira adequada. (DIETER et al., 2001) cita que existe um custo,
em tempo de execuo, envolvido com a atividade de manter a sincronizao dos objetos
mantidos por cada thread.
Para a utilizao do mecanismo libtckpt proposto por Dieter e Lump, algumas modificaes na aplicao so necessrias. O cdigo da aplicao onde deseja-se realizar a
persistncia de informaes deve ser modificado para incluir um header especial. Alm
da utilizao de um cabealho especial, a aplicao precisa ser modificada para realizar
a chamada de uma funo especial da biblioteca libtckpt para que a inicializao dos
componentes de checkpoint e restart seja realizada.
3.3.4
Score
Score uma abordagem proposta em (TAKAHASHI et al., 2000), que possibilita a

realizao de operaes de checkpoint em aplicaes paralelas. O modelo de soluo
disponvel no Score implementa as funcionalidades de checkpoint e restart nas camadas
mais baixas de comunicao e nas bibliotecas de runtime. Essa abordagem em baixas
camadas permite que aplicaes paralelas possam realizar checkpoints sem a necessidade
de sofrerem modificaes no cdigo fonte da aplicao.
Em (TAKAHASHI et al., 2000), o autor cita que alm da inexistncia de modificaes
no cdigo fonte de aplicao, para que a utilizao da biblioteca Score seja possvel,
apenas algumas poucas modificaes so necessrias nas camadas de comunicao de
alto-nvel, como por exemplo, MPI. Isso significa que, para uma aplicao paralela fazer
uso dos benefcios oferecidos pelo Score, apenas algumas modificaes na camada de
comunicao so necessrias.
Outra caracterstica do Score apresentada em (ROMAN, 2002) a capacidade de armazenar informaes de paridade em nodos remotos. Essa informao de paridade pode
ser utilizada para reconstruir um arquivo de checkpoint que possa estar armazenado em
um nodo que apresentou falhas. Isso permite que o estado consistente de uma aplicao
pode ser recuperado mesmo quando um arquivo de checkpoint seja perdido.
3.3.5
CoCheck
CoCheck uma soluo que permite a realizao de operaes de checkpoint em ambientes com aplicaes paralelas distribudas. Segundo (STELLNER, 1996), os ambientes de programao mais populares, como NXLib, P4, PVM ou MPI no disponibilizam
em suas solues mecanismos para a realizao de checkpoints. A soluo foi inicialmente projetada para servir como o passo inicial para permitir a migrao de tarefas entre
41
processos. A idia no CoCheck realizar as operaes de checkpoint para que as informaes projetadas possam ser armazenadas e transmitidas para outros processos de modo
que estes possam reiniciar as atividades no ponto em que foram previamente interrompidas.
Essa soluo permite habilitar a realizao de checkpoints em aplicaes que fazem
uso de troca de mensagens utilizando a MPI, objetivando facilitar eventuais operaes de
migrao de tarefas. Em (STELLNER, 1996), o autor menciona que CoCheck tem como
principal objetivo, alm de permitir a realizao de checkpoints em ambientes MPI, atingir
a maior portabilidade possvel. Pelo fato de tambm ser de interesse da soluo permitir
a realizao de operaes de checkpoint em outras bibliotecas, alm de MPI, mostra-se
interessante o projeto de uma soluo que seja independente das bibliotecas especficas de
MPI. Para que esses objetivos fossem possveis de serem atingidos, a soluo CoCheck
foi implementada como uma camada adicional, que executada sobre a biblioteca de
comunicao (que pode ser, por exemplo, MPI).
O CoCheck implementado tendo como base a premissa de transparncia na execuo
de checkpoints (STELLNER, 1996). Isso significa que as operaes de checkpoint devem
ser executadas de maneira transparente em relao a aplicao e camada para troca de
mensagens. Dessa forma, as aes de checkpoint so realizadas sem que a execuo da
aplicao seja prejudicada.
Um dos maiores problemas endereados pela soluo em questo o fato de que, no
momento em que o checkpoint executado, podem existir mensagens em trnsito, em
diversos lugares como na rede fsica, buffers dos sistemas operacionais ou at mesmo
nas filas das bibliotecas de troca de mensagens utilizadas. Para que o checkpoint possa
ser corretamente executado, importante que ele seja realizada no momento em que o
sistema se apresente em um estado global consistente (STELLNER, 1996).
Um estado global consistente pode ser definido como sendo o estado em que as informaes e dados estejam organizados de maneira consistente permitindo seu armazenamento e conseqente recuperao. Aplicaes paralelas podem ser definidas como sendo
um conjunto de processos que cooperam entre si para a realizao de uma determinada
tarefa atravs da troca de mensagens. Nessa abordagem, cada processo, se analisado individualmente, pode ser caracterizado como sendo uma seqencia finita e ordenada de
eventos. A organizao consistente desses eventos que garante a consistncia global ou
no da aplicao (STELLNER, 1996).
Para exemplificar o cenrio descrito acima, a figura 3.2 representa um ambiente computacional com trs processos. Cada vrtice da figura representa um evento e as setas
indicam as mensagens trocadas durante a execuo. As linhas pontilhadas S, S e S representam os estados globais da aplicao, isto , a maneira como a aplicao pode ser
vista sob um ponto de vista externo ao modelo. Com base nesse conceito, os cenrios
de estados globais onde seja possvel a interrupo da execuo e a correta recuperao
das atividades e retomada da execuo de maneira direta so chamados de estados globais
consistentes.
Para garantir que o checkpoint seja realizado no momento adequado, onde respeitase um estado global consistente, o CoCheck faz uso de mensagens especiais, chamadas
de RM - ready messages. Essas mensagens especiais so utilizadas para garantir que,
no momento de execuo do checkpoint, no existam outras mensagens em rede ou buffer que podem prejudicar o estado global consistente, tornando invivel a realizao do
checkpoint. Cada processo participante do ambiente computacional envia a RM para os
processos com os quais se comunica e estes, ao receber a notificao, repassam para os de-
42
Figura 3.2: Caracterizao de um Estado Global
Figura 3.3: Limpando Canais de Comunicao

mais. Receber uma RM de um determinado processo significa que o processo que enviou
a RM no possui mais mensagens de comunicao a ser repassada. Quando o momento
em que todos os processos receberam um RM alcanado, o estado global consistente
obtido e a operao de checkpoint pode ser realizada com segurana, de modo que as
informaes sejam passveis de recuperao no futuro (STELLNER, 1996).
A figura 3.3 apresenta o efeito prtico das trocas de mensagens RM entre os processos
participantes (STELLNER, 1996). Nela possvel identificar que todas as mensagens que
esto em trnsito antes do envido RM so entregues e adicionadas ao buffer do processo
destino. Nesse mesmo fluxo, quando um determinado processo j coletou as RMs de todos os demais possvel assumir que no existem mais mensagens a serem transmitidas e
as que estavam em trnsito j esto armazenadas de maneira segura em algum dos buffers
para acesso posterior. Quando esse cenrio atingido, possvel que as operaes de
checkpoint sejam realizadas de maneira consistente, possibilitando a recuperao correta
das informaes, bem como habilitando que as tarefas sejam migradas entre os processos
com segurana.
3.3.6
Esky
Esky uma implementao de soluo para checkpoint/restart focada em processos

Unix, totalmente implementada em nvel de usurio, sem a necessidade de utilizao de
patches ou mdulos. A ltima verso estvel da soluo funciona em ambientes Linux
43
(2.2.x) e Solaris (2.6), independente do tipo de CPU utilizada.

O projeto inicial tinha como premissas permitir a realizao de checkpoint para a
plataforma Solaris, de maneira transparente, sem a necessidade de modificaes invasivas
no kernel do sistema operacional nem mesmo no cdigo fonte da aplicao. O processo de
checkpoint do esky controlado atravs de um monitor, que intercepta as chamadas para
funes realizadas pelo processo alvo. Isso realizado atravs da utilizao da varivel
de ambiente LD_PRELOAD. Apesar de no serem necessrias modificaes no kernel
do sistema operacional nem no cdigo fonte da aplicao, a aplicao alvo deve ser relinkada de maneira dinmica (GIBSON, 2009).
Entre as limitaes do Esky, (GIBSON, 2009) cita que no possvel realizar checkpoint para programas paralelos ou multi-threads. Alm disso, o Esky assume que o contedo de arquivos abertos considerados no checkpoint no ser modificado at que o restart seja efetuado. Caso o contedo dos arquivos seja modificado no espao de tempo
entre um checkpoint e o restart, as informaes sero desconsideradas.
3.3.7
Dynamit
Dynamit uma soluo que prov o balanceamento de carga dinmico, para sistemas
PVM 2 . Por ser construda com foco em sistemas PVM, a soluo tambm chamada
Dynamic PVM freqentemente representada pelo acrnimo DPVM. Nessa soluo, as tarefas so migradas, de maneira transparente, entre os nodos para manter o melhor balanceamento possvel. Para permitir a migrao de tarefas, o DPVM possui um mecanismo
de checkpoint implementado (OVEREINDER et al., 1996).
O DPVM consiste, basicamente, em trs componentes principais:
Escalonador, que responsvel por distribuir as tarefas de maneira equilibrada e
consistente;
Monitor, que responsvel por monitorar a carga de trabalho dos recursos do cluster;
Checkpointer, responsvel por persistir as informaes produzidas e permitir que o
mecanismo de migrao de tarefas seja possvel.
A verso atual do DPVM suporta apenas PVM, mas os autores do modelo citam em
(OVEREINDER et al., 1996) que pesquisas esto sendo realizadas de modo a ampliar a
cobertura para suportar MPI tambm. O mecanismo de checkpoint implementado pelo
DPVM oferece, conforme citado em (OVEREINDER et al., 1996) algumas vantagens
como:
Tolerncia a falhas, pois permite que checkpoints regulares possam ser realizados
de maneira frequente;
Possibilita a migrao de processos;
Permite a realizao de rollback de transaes.
2
PVM um pacote de software que permite que uma rede heterognea de computadores possa ser
programada como sendo uma nica mquina paralela virtual.
44
Como descrito em (OVEREINDER et al., 1996), quando a operao de checkpoint

realizada, o espao de endereos, juntamente com as bibliotecas compartilhadas do
processo que est sendo persistido so mapeados e escritos em um arquivo em disco.
Esse processo realizado atravs de sinais SIGUSR13 .
3.4
Implementaes em nvel de Sistema Operacional
De acordo com (LAADAN et al., 2005), abordagens de checkpoint realizadas diretamente atravs de operaes do sistema operacional, oferecem uma grande transparncia
aplicao, pois nenhuma modificao explcita precisa ser feita, nem mesmo recompilao da aplicao. Entretanto, so necessrias modificaes extremamente invasivas no
sistema operacional.
As sees abaixo apresentam algumas das solues desenvolvidas que oferecem meios
para a realizao de checkpoint atravs do sistema operacional.
3.4.1
VMADump
A utilizao do Virtual Memory Area Dumper possibilita capturar a execuo de um

determinado processo e copi-lo para um nodo remoto, permitindo a continuidade de
execuo do mesmo. VMADump permite que o espao de memria de um processo seja
armazenado e recuperado, de maneira consistente, permitindo a interrupo e retomada
de execues (HENDRIKS, 2009).
A maioria dos programas em execuo no sistema so linkados de maneira dinmica
(HENDRIKS, 2009). Em tempo de execuo, essas aplicaes utilizam mmap para obter
cpias das vrias bibliotecas, nos seus espaos de memria especfico. Como as bibliotecas so sempre copiadas por inteiro para o espao de memria, mesmo que apenas uma
pequena parte dela seja de fato utilizada pela aplicao, o processo se torna custoso.
Para exemplificar, a listagem abaixo apresenta o espao de memria do programa
sleep, obtido de /proc/pid/maps:
Listing 3.3: Dump de memria do sleep
... 08049000
. . . 0 8 0 4 a000
... 40012000
... 40013000
... 40102000
... 40106000
. . . 4 0 1 0 a000
. . . c0000000
rxp
rwp
rxp
rwp
rxp
rwp
rwp
rwxp
00000000
00000000
00000000
00012000
00000000
000ea000
00000000
fffff000
03:01
03:01
03:01
03:01
03:01
03:01
00:00
00:00
288816
288816
911381
911381
911434
911434
0
0
/ bin / sleep
/ bin / sleep
/ lib / ld 2 . 1 . 2 . so
/ lib / ld 2 . 1 . 2 . so
/ lib / libc 2 . 1 . 2 . so
/ lib / libc 2 . 1 . 2 . so
Para essa aplicao simples, so necessrios 1.089.536 bytes, sendo que tudo, exceto
32K, so informaes referentes a bibliotecas compartilhadas.
justamente essa grande quantidade de informaes referentes a bibliotecas compartilhadas que VMADump procura evitar de copiar. (HENDRIKS, 2009) cita que a cpia
de informaes de bibliotecas compartilhadas pode ser evitada no momento de migrao
de processos para mquinas remotas se for possvel garantir que as mesmas bibliotecas
existem na mquina destino. VMADump armazena referncias s regies relacionadas
a bibliotecas compartilhadas ao invs de armazenar a prpria informao, fazendo que o
tamanho da informao seja consideravelmente menor.
3
SIGUSR1 e SIGUSR2 so sinais enviados para um determinado processo para indicar a existncia de
condies pr-definidas pelos usurios.
45
Em (HENDRIKS, 2009), o autor aponta como limitao do VMADump o fato de

ser possvel realizar a serializao de apenas uma thread em aplicaes multi-thread.
Alm disso, VMADump no se preocupa com as informaes referentes a descritores de
arquivos, de modo que no capaz de persistir e, por consequncia, recuperar esse tipo
de informao.
3.4.2
EPCKPT
EPCKPT um mecanismo para realizao de checkpoint/restart desenvolvido pela

Universidade Federal do Rio de Janeiro. A soluo foi criada tendo em mente a migrao
de processos, o que faz com que a preocupao em termos do tamanho das informaes
produzidas seja constante. Essa preocupao com o tamanho das informaes de checkpoint relevante quando se pensa na transferncia dos dados para possibilitar a migrao
dos processos (PINHEIRO, 1998).
A soluo bastante similar ao esquema desenvolvido pelo VMADump. Assim como
o VMADump, a soluo desenvolvida pela Universidade Federal do Rio de Janeiro tambm implementada no segmento esttico do kernel do sistema operacional. Entretanto,
(PINHEIRO, 1998) destaca que o EPCKPT oferece uma transparncia maior nas execues dos checkpoints, se comparado ao VMADump. Essa maior transparncia na execuo est relacionada com a utilizao do PID original do processo, ao invs de utilizar uma
macro, como o modelo seguido pelo VMADump (SANCHO et al., 2005). o EPCKPT, de
acordo com (PINHEIRO, 1998) fornece uma srie de melhorias se comparado s demais
solues para realizao de checkpoint. Algumas dessas caractersticas so levantadas
pelos autores:
Permite a realizao de checkpoints em diversos tipos de aplicaes. Por ser uma
soluo desenvolvida dentro do kernel linux, possvel ter acesso a informaes
que permitem capturar informaes importantes para armazenamento dos dados e
futura recuperao;
Tamanho do checkpoint mnimo. Como o EPCKPT tem como principal preocupao a migrao de processos, existe uma preocupao constante em relao ao
tamanho fsico das informaes produzidas, para que seja mnimo o esforo necessrio para a migrao;
Checkpoint transparentes de aplicaes. Por ser implementado em nvel de sistema
operacional, toda aplicao pode ser persistida sem a necessidade de modificao,
de maneira totalmente transparentes;
Checkpoint de aplicaes paralelas. A implementao em nvel de sistema operacional permite que se tenha acesso a informaes que tenham chamado operaes de
fork(), exec() e mmap();
O incio de uma operao de checkpoint atravs do EPCKPT pode ser realizada de
duas maneiras: atravs de envio de sinais ao kernel ou acionado diretamente pelo usurio.
Para que a segunda abordagem fosse possvel, a soluo desenvolvida por (PINHEIRO,
1998) disponibiliza uma srie de ferramentas que possibilitam a chamada direta, por parte
do usurio, das aes para realizao de checkpoints.
46
3.4.3
CRAK
CRAK uma soluo de mecanismo para checkpoint/restart inicialmente proposta e

apresentada em (ZHONG; NIEH, 2002). Essa soluo foi projetada para ser adaptada
como um mdulo a ser adicionado ao kernel do sistema operacional Linux. A premissa
inicial que os autores tentaram seguir com a implementao do CRAK a de manter o
ndice de modificao, tanto em termos de sistema operacional no menor ndice possvel,
e inexistente em termos de aplicao (ZHONG; NIEH, 2002). Isso significa que para a
utilizao do CRAK no necessrio nenhuma alterao no cdigo da aplicao que est
sendo utilizada; entretanto, o sistema operacional deve sofrer uma pequena alterao para
que o mdulo responsvel pela realizao das operaes de checkpoint seja adicionado e
instalado.
As operaes realizadas pelo mecanismo CRAK de checkpoint podem ser divididas,
de acordo com (ROMAN, 2002) em duas macro-atividades. A primeira, realizada no
espao de dados do usurio, responsvel por identificar o conjunto de processos em
que se deseja aplicar as operaes de checkpoint, isto , realizar o levantamento de quais
aplicaes sero passveis de terem seu estado persistido para uma posterior recuperao.
CRAK permite que essa atividade de identificao de processos e atividades a serem
persistidas seja identificada de trs maneiras distintas:
1. Realizao de checkpoint sobre apenas um processo simples;
2. Realizao de checkpoint sobre os filhos de um determinado processo;
3. Realizao de checkpoint sobre um processo e todos os seus filhos;
Aps identificados os processos a serem persistidos durante a execuo do checkpoint, o CRAK envia um sinal SIGSTOP, indicando que os processos devem ser temporariamente interrompidos. Dessa forma, com todos os processos momentaneamente
suspensos, o ambiente computacional se apresenta em uma forma consistente, permitindo
que as operaes de checkpoint sejam corretamente executadas.
Nesse momento, quando os processos esto suspensos e aptos a terem suas informaes persistidas, entra a segunda etapa do processo, realizada no kernel do sistema
operacional. As informaes so ento persistidas em meio fsico e o CRAK envia ento
um sinal SIGCONT indicando aos processos que as suas atividades normais de execuo
podem ser retomadas ou, opcionalmente, finalizadas se for o caso.
As informaes persistidas pelo CRAK durante a execuo de checkpoints contemplam credenciais dos processos que foram persistidos, informaes sobre memria virtual, sinais ativos e sinais pendentes, o diretrio corrente de trabalho alm de informaes
sobre arquivos abertos ou em uso (ROMAN, 2002). Em (ZHONG; NIEH, 2002), mencionado que durante a execuo de um checkpoint, caso existam arquivos regulares sendo
manipulados, as informaes referentes ao nome do arquivo, modo de acesso, flags diversas e a posio onde o arquivo estava sendo modificado (ou acessado) armazenada.
Essas informaes so posteriormente utilizadas, no processo de restart, permitindo que
o arquivo seja reaberto e posicionado no exato ponto onde estava sendo previamente modificado.
Em (ZHONG; NIEH, 2002; ROMAN, 2002) os autores levantam como caracterstica
relevante do CRAK a possibilidade de realizao de operaes de checkpoint em mltiplos processos. Entretanto, (ROMAN, 2002) afirma que o mesmo no possvel para
processos multi-threads, j que o CRAK no est preparado para compreender acesso a
47
reas de memria compartilhada. Isso significa que atravs da utilizao do CRAK

possvel realizar operaes de checkpoint e persistir dados referentes a aplicaes com
mltiplos processos, porm o mesmo no vlido para aplicaes que fazem uso de compartilhamento de memria para resoluo de algoritmos.
Apesar do CRAK implementar uma srie de requisitos interessantes e desejveis para
um mecanismo de checkpoint, ele no pode ser considerado como uma soluo genrica.
Em (ROMAN, 2002) o autor cita justamente que essas limitaes em relao realizao
de checkpoints para processos multi-threads prejudica a utilizao da soluo de maneira
ampla. Outra limitao do CRAK apontada em (ROMAN, 2002) o fato de no permitir o registro direto, pelos usurios, de handlers para a realizao de checkpoints. Em
(ZHONG; NIEH, 2002) o autor tambm menciona a falta de possibilidade de interromper
ou evitar a execuo de checkpoints. Isso significa que quando CRAK utilizado, no
existem mecanismos para suspender ou evitar a realizao de checkpoints.
3.4.4
Zap
ZAP foi inicialmente apresentado em (OSMAN et al., 2002) e pode ser definido como
um sistema que permite a migrao, de maneira transparente, de aplicaes em um ambiente de rede. ZAP foi projetado como uma soluo que adiciona uma fina camada
de virtualizao sobre o sistema operacional, tendo como principal diferencial a criao
de PODs. POD um grupo de processos organizados de maneira consistente, proporcionando uma camada virtualizada do ambiente computacional e do sistema envolvido
(OSMAN et al., 2002).
Essa organizao feita atravs de POD permite o desacoplamento da aplicao em relao ao sistema operacional, o que permite que, sendo atingido um estado consistente de
execuo, o processo possa ter suas informaes serializadas - atravs de um checkpoint
- e, se for de interesse, seja migrado para outro local. Esse desacoplamento permite que,
aps realizado o checkpoint, as informaes possam ser transferidas entre diferentes mquinas, permitindo que a execuo do processo seja retomada sem a perda de resultados e
evitando que resduos de informaes fiquem perdidos no ambiente original de execuo
(OSMAN et al., 2002).
A idia principal implementada pelo Zap a de eliminar qualquer vnculo entre a aplicao a ser executada e o sistema operacional. Todas as informaes relativas execuo,
como por exemplo, ponteiros para arquivos, sockets e similares so contidos dentro de
uma camada de abstrao. No momento de execuo do checkpoint, todas as informaes que esto armazenadas nesse namespace especial criado pelo Zap so armazenadas
e transmitidas para que possam, futuramente, serem utilizadas para a retomada de um
estado consistente. Zap pode ser entendido como uma soluo complementar ao CRAK:
complementar pelo fato de que o Zap adiciona uma camada de virtualizao sob o sistema
operacional, ao contrrio do CRAK (visto neste mesmo captulo). O Zap, se entendido
como uma ferramenta para migrao de processos, utiliza o CRAK como mecanismo para
realizao de checkpoint.
Em (OSMAN et al., 2002) aponta como principais caractersticas do Zap a transparncia em relao s aplicaes. Pelo fato da soluo ser implementada como uma camada
de virtualizao sob o sistema operacional Linux, no existe a necessidade de modificaes invasivas no sistema operacional, nem mesmo modificaes especficas no cdigo
da aplicao que se deseja persistir e migrar.
48
3.4.5
BLCR
Berkeley Lab Checkpoint/Restart uma soluo que faz parte da Scalable Systems
Software Suite, desenvolvida pelo Future Technologies Group do Lawrence Berkeley National Lab, financiado pelo departamento de energia dos Estados Unidos. uma soluo
open-source implementada sob a licena GPL (HARGROVE; DUELL, 2006). O BLCR
permite a realizao de checkpoints e foi projetado, principalmente, para aplicaes HPC.
uma soluo criada para atuar em nvel de sistema operacional, e foi desenvolvida como
um mdulo que pode ser adicionado ao kernel Linux. Segundo (HARGROVE; DUELL,
2006), a soluo foi inicialmente projetada para ser executada no Linux 2.4.x e Linux
2.6.x em arquiteturas x86 e x86-64.
De acordo com (PENG; KIAN, 2009), o BLCR um mdulo para Kernel Linux que
permite armazenar o estado de um processo em um disco fsico, possibilitando a sua futura
recuperao em memria. O arquivo criado em disco, chamado de arquivo de contexto,
contem todas as informaes necessrias para retomar a execuo normal de um processo
que tenha sido interrompido. Em (PENG; KIAN, 2009; HARGROVE; DUELL, 2006) os
autores citam que um arquivo de contexto pode ser criado a qualquer momento durante
a execuo de um processo. Com o arquivo de contexto corretamente armazenado, a
execuo do processo pode ser retomada a qualquer momento no futuro, at mesmo em
recursos ou mquinas diferentes.
O BLCR foi criado tomando como base as funcionalidades existentes na soluo
VMADump, descrita nesse mesmo captulo, sendo que adaptaes especficas foram realizadas pelos autores a fim de adequar o BLCR s necessidades especficas do laboratrio
(PENG; KIAN, 2009). Segundo os mesmos autores, a soluo mantida como um mdulo a parte, distinto do VMADump por questes de manuteno, j que os binrios so
diferentes.
Em (HARGROVE; DUELL, 2006), o autor apresenta algumas limitaes da soluo:
BLCR no suporta a realizao de checkpoint para grupos de processos. Isso significa que apenas processos individuais podem ser contemplados em operaes de
checkpoint;
Para que a operao de restart seja realizada com sucesso o PID do processo original que est sendo recriado no pode estar em uso;
O processo de restart somente ser realizado com sucesso se os originais utilizados
no momento da criao do arquivo de contexto bem como as bibliotecas compartilhadas utilizadas pelo processo estiverem disponveis e na mesma verso utilizada
no momento do checkpoint;
3.4.6
UCLiK
UCLiK (FOSTER, 2003), abreviao para Unconstrained Checkpointing in the Linux

Kernel um mdulo de kernel que permite aos usurios do sistema operacional a realizao de operaes de checkpoint e restart de processos de maneira transparente. Foi
inicialmente projetado para o kernel do Linux na verso 2.4.19, mas disponibiliza atualizaes para verses recentes do kernel LINUX.
UCLiK foi construdo tendo como base a soluo CRAK tambm apresentada nesse
captulo. A principal diferena entre CRAK e UCLiK que este ltimo enderea melhorias em relao a manipulao de arquivos. Segundo (SANCHO et al., 2005), quando do
49
momento de restart de um processo, UCLiK capaz de recuperar o PID original do processo, bem como todo o contedo do mesmo, alm de identificar os arquivos que foram
excludos durante o processo.
3.4.7
CHPOX
CHPOX foi inicialmente apresentado em (SUDAKOV et al., 2007) oferece uma soluo transparente para realizao de checkpoints e a conseqentes restarts de processos
em clusters Linux. O projeto inicial do CHPOX tinha como objetivo permitir a recuperao de tarefas de longa durao, como por exemplo simulaes numricas, em caso de
quebras de sistema, quedas de energia e outros problemas semelhantes.
A soluo foi criada tendo como base para desenvolvimento o EPCKPT, com o diferencial de ser implementado como um mdulo do kernel do linux. Outra diferena em
relao ao EPCKPT o fato de que o CHPOX armazena o estado dos processos envolvidos de maneira local. Isso feito, atravs da criao de uma nova entrada no sistema de
arquivos do sistema operacional e de um evento no kernel - SIGSYS (SUDAKOV et al.,
2007).
Para que o mecanismo de checkpoint/restart do CHPOX possa ser utilizado, necessrio que a aplicao em questo se registre atravs do envio do seu PID para que seja
armazenado na entrada do sistema de arquivos, mencionada acima. Com o identificador
do processo em que deseja-se aplicar o checkpoint armazenado, a execuo das operaes
de checkpoints so iniciadas atravs do envio de sinais SIGSYS para o processo.
A soluo CHPOX SMP-Safe e, para sua utilizao, no necessrio que a aplicao
seja recompilada nem mesmo re-linkada. Segundo (SUDAKOV et al., 2007), CHPOX
oferece suporte a utilizao de dados em memria virtual, assim como capaz de persistir
corretamente informaes referentes a arquivos abertos. Outra caracterstica do CHPOX
citada em (SUDAKOV et al., 2007) a possibilidade de persistir, nas informaes de
checkpoint, dados sobre os processos filhos.
O multiprocessamento simtrico uma tecnologia que permite a um determinado sistema operacional distribuir tarefas entre dois ou mais processadores, permitindo que vrios processadores compartilhem o processamento de instrues requisitadas pelo sistema.
O multiprocessamento simtrico oferece um aumento linear na capacidade de processamento a cada processador adicionado. No h necessariamente um hardware que controle
este recurso, cabe ao prprio sistema operacional suport-lo.
3.4.8
PsncR/C
PsncR/C um mecanismo para checkpoint/restart proposto em (MEYER, 2003), direcionado para plataformas SUN. implementado atravs de threads diretamente no kernel
do sistema operacional, sendo disponvel como um mdulo adicional ao kernel. Durante a
execuo do checkpoint, todas informaes referentes ao estado dos processos envolvidos
sero persistidos em disco.
De acordo com (MEYER, 2003), uma nova entrada no sistema de arquivos /proc
criada e todas as operaes de checkpoint so realizadas atravs da interface iotcl.
Por no possuir preocupaes especficas relacionadas com a otimizao de dados para
reduzir o tamanho fsico em disco das informaes de checkpoint, todas as bibliotecas
compartilhadas, cdigos utilizados e arquivos abertos so invariavelmente includos nos
checkpoints.
50
3.5
Persistncia Ortogonal
Um sistema persistente, segundo (ATKINSON; MORRISON, 1995), lida com as informaes que esto armazenadas em meio fsico permanente, como sendo uma extenso
estvel da memria voltil. Nessa viso, os objetos podem ser dinamicamente manipulados, modificados e alocados em memria, mas seus respectivos dados so persistidos
entre as execues de um determinado programa. Isso significa que, em um sistema persistente, mesmo as informaes armazenadas somente em memria so mantidas entre as
execues de uma determinada aplicao.
Os princpios de transparncia e ortogonalidade so amplamente discutidos e considerados como fundamentais no projeto de uma linguagem de programao persistente
(ATKINSON; MORRISON, 1995). Com esses princpios bsicos observados, a abstrao
de persistncia pode ser disponibilizada, em seu total potencial.
O conceito de transparncia, nesse contexto, significa que, sob a perspectiva do programador do sistema, o acesso aos objetos persistentes no requer a escrita de comandos ou instrues especficas. Isso faz com que a transferncia dos objetos do meio de
persistncia estvel para a memria seja completamente transparente, em termos de desenvolvimento (ATKINSON; MORRISON, 1995). Com isso, aplicaes que manipulam
objetos potencialmente persistentes so muito semelhantes com aplicaes que somente
manipulam objetos transientes, em memria. Em termos de funcionalidade, o conceito
de transparncia permite que, ao invs de instrues explcitas de leitura e escrita, o compilador ou sistema de run-time envolvido persiste os dados, de maneira automtica, em
cache, conforme demanda da aplicao.
Por ortogonalidade devemos entender como a possibilidade de tornar a linguagem
de programao persistente, com o mnimo de modificaes ou alteraes na sintaxe j
existente, mantendo a semntica j definida (MOSS; HOSKING, 1996). Em um sistema
persistente ortogonal, essa premissa observada e todo e qualquer objeto criado passa a
ser persistente, de maneira automtica, a partir do momento em que referenciado por
um objeto j persistente (ATKINSON; MORRISON, 1995). Com esse conceito de ortogonalidade, os programadores precisam de poucos ajustes em termos de conhecimento da
linguagem para poderem fazer uso dos benefcios da persistncia.
Em (ATKINSON; MORRISON, 1995), os autores citam que um mecanismo comum
para habilitar o conceito de persistncia ortogonal em uma linguagem de programao,
tratando o mecanismo de persistncia estvel como uma extenso das informaes que
so alocadas dinamicamente em heap. Isso permite que os dados transientes e os dados
persistentes sejam tratados de maneira uniforme e transparente.
O conceito de persistncia ortogonal foi desenvolvido e melhorado ao longo dos anos
de pesquisa, na comunidade acadmica. Esse conceito estabelece trs principios bsicos
que caracterizam a ortogonalidade, que so independentes da linguagem de programao
em que sejam implementados:
Ortogonalidade de tipo: a persistncia deve ser possvel e estar disponvel para todo
e qualquer dado, independente do seu tipo.
Persistncia Transitiva 4 : o ciclo de vida de todos os objetos determinado pelo
alcance, a partir de um determinado objeto raiz.
Independncia de Persistncia: a persistncia dos dados deve ser independente de
como o programa manipula essas informaes.
51
A aplicao desses trs princpios produz um mecanismo de persistncia ortogonal.

Segundo (DEARLE et al., 2009) a violao de qualquer uma dessas premissas acarreta o
aumento da complexidade, que um sistema persistente procura sempre evitar.
Diversas linguagens de programao oferecem implementaes ou verses que disponibilizam o conceito de persistncia ortogonal. Abaixo so apresentadas algumas dessas
linguagens, junto com uma breve descrio.
3.5.1
PS-Algol
Foi a primeira linguagem de programao a disponibilizar o conceito de persistncia

ortogonal (DEARLE et al., 2009). PS-Algol uma soluo que adiciona um pequeno
nmero de funes especficas na linguagem S-Algol, da qual deriva.
O exemplo de cdigo apresentado abaixo, retirado de (ATKINSON et al., 1990), apresenta o funcionamento da linguagem PS-Algol, em termos de sua persistncia ortogonal:
Listing 3.4: Persistncia ortogonal com PS-Algol
structure person ( string name , phone ; pntr addr )
structure address ( i n t no ; string street , town )
let db = open . database ( " a d d r . db " , " w r i t e " )
i f db is error . record
do { write " Can t open d a t a b a s e " ; abort }
let table = s . lookup ( " a d d r . t a b l e " , db )
let p = person ( " a l " , 3 2 5 0 ,
address ( 7 6 , " N o r t h S t " , " S t Andrews " ) )
s . enter ( " a l " , table , p )
commit
Nesse exemplo, a base de dados addr.db aberta e um objeto person criado.

Note que tambm criado um objeto address que associado ao objeto person previamente criado. No momento em que a instruo de commit, chamada, de maneira
transparente e ortogonal, ambos objetos so armazenados para posterior consulta.
3.5.2
Napier88
Napier88 uma implementao que tenta explorar os limites da persistncia ortogonal

atravs da incorporao de todo o ambiente de suporte da linguagem de programao
(ATKINSON et al., 1990). A linguagem Napier88 foi inicialmente concebida por Ron
Morrison e Malcolm Atkinson, com projeto e primeira implementao feita por Fred
Brown, Richard Connor, Alan Dearle e Ron Morrison (ATKINSON et al., 1990).
O modelo proposto pelo Napier88 consiste de uma linguagem de programao e seu
ambiente persistente. A implicao do conceito de persistncia ortogonal implica no fato
de no ser necessrio converter ou mover, de maneira explcita, os dados de memria para
um meio fsico persistente, seja para dados temporrios ou permanentes (ATKINSON
et al., 1990). O modelo de persistncia do Napier88 obtido atravs da utilizao de um
objeto raiz persistente, onde todos os objetos derivados deste assumem a propriedade de
persistncia tambm (BROWN, 1988).
O sistema Napier88 foi projetado como uma arquitetura em camadas, composta basicamente por trs nveis: o compilador, a mquina abstrata de persistncia (PAM, do ingls
4
A persistncia transitiva um conceito que deriva do Principle of Persistence Identification, definido

em (ATKINSON; MORRISON, 1995).
52
Persistent Abstract Machine) e o componente para armazenamento persistente (BROWN,

1988). Todas essas camadas definidas pela arquitetura so virtuais, no sentido de no
ser especfico o modo como sejam implementadas. Isso significa que as camadas do Napier88 podem ser implementadas de maneira totalmente independente ou agrupada, de
acordo com os requisitos de desempenho que estejam associados ao modelo (BROWN,
1988; ATKINSON et al., 1990, 1996).
3.5.3
Arjuna
O foco do Arjuna oferecer um conjunto de ferramentas para possibilitar a criao de

aplicaes distribudas tolerantes a falhas. De acordo com (PARRINGTON et al., 1995;
SHRIVASTAVA et al., 1991), isso obtido atravs da utilizao de objetos persistentes
atravs do conceito de ortogonalidade, possibilitando a realizao de transaes atmicas aninhadas. Por transaes atmicas o autor se refere propriedade de atomicidade,
associada s transaes.
Para tornar possvel a persistncia e recuperao dos objetos, um snapshot tirado
antes das modificaes serem realizadas dentro do escopo da transao atmica, conforme descrito em (PARRINGTON et al., 1995). Com esse mecanismo, antes de iniciar
a execuo de qualquer trecho crtico (transao atmica) o estado geral de execuo
armazenado, sendo substitudo ao final da transao caso esta tenha sido efetivada com
sucesso. Em caso de ocorrncia de falhas, o estado armazenado antes da transao
recuperado e utilizado como base para o re-incio das atividades de processamento.
Uma aplicao Arjuna consiste de uma ou mais transaes atmicas criadas para controlar uma coleo de operaes realizadas em objetos da linguagem. Esses objetos so,
por definio, uma instncia de um tipo abstrato de dados (uma classe C++) que pode ser
persistido de modo a continuar existindo mesmo aps o trmino de execuo da aplicao. Em (SHRIVASTAVA et al., 1991) o autor menciona que a partir da garantia de que
toda manipulao de objetos seja realizada por meio de transaes atmicas, possvel
afirmar que a integridade dos objetos e das informaes ser garantida em caso de falhas
ocorridas.
3.5.4
Persistent Java
PJama (ATKINSON et al., 1996) uma das implementaes de ortogonalidade da

plataforma Java. Nessa implementao, o programador da aplicao utiliza uma API especfica para realizar o mapeamento dos objetos com strings em um mapa persistente.
Dessa forma, todos os objetos transientes que estejam associados com um registro nesse
mapa, passam a ser persistidos.
A implementao do PJama, segundo (ATKINSON et al., 1996), no traz alteraes
linguagem de programao em si, nem mesmo necessita de modificaes no compilador
e nas bibliotecas padro. Entretanto, alteraes na mquina virtual so necessrias para
permitir a manipulao dos objetos da memria para o ambiente de persistncia, e viceversa.
Mquinas virtuais podem ser definidas como um sistema computacional que implementado em termos de software, usualmente sendo executado dentro de um computador
real. Nos termos que sero utilizados aqui, mquinas virtuais devem ser entendidas como
as solues responsveis por encapsular a execuo de uma aplicao (um programa Java
ou C#, por exemplo).
A mquina virtual do Java (JVM) um conjunto de programas e estruturas de dados que usam um modelo de mquina virtual para a execuo de outros programas ou
53
scripts, desenvolvidos em uma linguagem intermediria chamada de bytecode. Como outro exemplo, o CLR a mquina virtual oferecida pela plataforma .NET. semelhante
implementao da JVM, sendo responsvel pela execuo de aplicaes em linguagem
intermediria CIL, tambm chamada de MSIL.
3.5.5
Outras Solues para Persistncia Ortogonal
Alm das diversas linguagens de programao que oferecem suporte persistncia

ortogonal, sistemas gerenciadores de banco de dados orientados a objetos tambm podem ser listados aqui. Como exemplo, pode-se citar DB4O, que pode ser utilizado nas
plataformas Java e .NET. DB4O no requer o mapeamento explcito entre os dados persistentes e transientes, de modo que a persistncia das informaes fica transparente ao
usurio (CORPORATION, 2009), como mostrado no trecho de cdigo abaixo:
Listing 3.5: Persistncia ortogonal utilizando DB4O
ObjectContainer db=Db4o . openFile ( Util . DB4OFILENAME ) ;
try {
Person al = new Person ( " a l " , 4 9 ) ;
db . set ( al ) ;
}
finally {
db . close ( ) ;
}
Nesse exemplo, um objeto Person persistido, de maneira transparente. Note que

essa transparncia faz com que os objetos armazenados na base de dados sejam POJOs
sem interface extras, extenses de classes ou anotaes.
Outra soluo, apresentada em 2002 Java Data Objects (PROCESS, 2009). JDO
oferece um mecanismo para persistncia de objetos java, sem a necessidade de utilizar
linguagens de acesso a dados, como SQL. Utilizando JDO, os objetos podem ser armazenados em bancos de dados relacionais, banco de dados orientado a objetos, arquivos
XML ou outras tecnologias semelhantes.
A API de persistncia do Java (MICROSYSTEMS, 2009) foi projetada para atuar
dentro e fora do container J2EE, criando um modelo persistente para objetos Java. Essa
API tambm tinha como objetivo reduzir a complexidade do JDO, retirando a necessidade
do mapeamento das informaes em arquivos de XML de configurao.
A Microsoft, reconhecendo a existncia de problemas para criao e utilizao de
consultas em strings dentro do cdigo das aplicaes, criou o Language-Integrated
Query, LINQ (KULKARNI et al., 2009). LINQ tem a abordagem de tratar a consulta
em dados relacionais como sendo apenas uma das opes para busca. Isso significa que,
atravs de LINQ, realizar buscas em base de dados relacionais, base de dados orientadas
a objetos ou colees de objetos mantidas em memria so equivalentes. Dessa forma,
possvel escrever aplicaes que fazem buscas em memria ou em base de dados relacionais, da mesma forma. O trecho de cdigo abaixo apresenta um exemplo de busca de
Pessoas em uma determinada coleo:
Listing 3.6: Busca atravs de LINQ
s t a t i c v o i d doquery ( Person [ ] people )
{
IEnumerable<Address> result = from p in people
where p . age == 49
select p . address ;
54
foreach ( Address item in result )

Console . WriteLine ( item . getTown ( ) ) ;
}
3.6
Outras Implementaes
Existe uma quantidade significante de solues para checkpoint de aplicaes de longa

durao. Alm das implementaes mais populares, citadas e detalhadas nesse captulo,
uma grande quantidade de solues, de menor expresso ou utilizao, foram deixadas
de fora dessa anlise. Dentro dessa linha, possvel destacar a participao de grandes
empresas privadas que participam ativamente do desenvolvimento de solues para checkpoint. A SGI disponibiliza uma implementao de mecanismo de checkpoint/restart para
o sistema operacional IRIX. Essa soluo de cdigo fechado e disponibilizada como
parte do kernel do IRIX. A Cray implementou um mecanismo de checkpoint/restart para
os sistemas operacionais Unicos e Unicos/mk, tambm de cdigo fechado. Acredita-se
que essas solues sejam os produtos mais robustos que existem atualmente. Entretanto,
no possvel apresentar maiores detalhes das solues pois no existem documentao
ou informaes pblicas disponveis, descrevendo detalhes sobre a implementao.
O centro de supercomputao de Pittsburgh projetou e implementou uma soluo para
checkpoint e restart em nvel de usurio para sistemas TCS. Esse sistema de checkpoint
permite a recuperao automtica de jobs em caso de falhas nas mquinas ou em perodos
de manuteno de equipamentos. Segundo (STONE et al., 2009) a soluo pode ser utilizada para maximizar a utilizao dos equipamentos atravs do armazenamento perodico
das informaes intermedirias produzidas. Foi projetado para ser acessvel para aplicaes C, C++ e Fortran. A soluo criada pelos laboratrios do centro de supercomputao
de Pittsburgh foi inicialmente projetado para suprir trs requisitos bsicos: permitir a recuperao de jobs em casos de falhas, ser escalvel e exercer efeito mnimo no tempo de
execuo do job (STONE et al., 2009).
Carothers e Szymanski descrevem em (CAROTHERS; SZYMANSKI, 2002) um mecanismo de checkpoint implementado em nvel de sistema para programas multi-threads
executados no sistema operacional Linux. Nessa proposta, uma nova chamada de sistema
operacional introduzida, sendo responsvel por realizar uma cpia da aplicao, utilizando um mecanismo copy-on-write semelhante aos utilizados pela chamada fork. O novo
processo criado pela chamada mencionada permanece em memria, no sendo realizada
a persistncia em disco. Apesar de ter a vantagem de ser bastante rpida, oferece a limitao de no tolerar falhas como reboot ou quedas de energia, visto que as informaes
so mantidas totalmente em memria.
StarFish um ambiente para execuo de aplicaes MPI-2 (dinmicas e estticas)
em clusters de workstations. Trata-se de um ambiente eficiente, tolerante a falhas, com
alta disponibilidade que permite comunicao em grupo de maneira flexvel e portvel
(AGBARIA; FRIEDMAN, 1999). Esse ambiente tambm oferece um mecanismo de
checkpoint/restart, com a limitao de estar disponvel apenas para aplicaes escritas
em Ocaml. O mecanismo tambm necessita intervenes do usurio para sincronizao
dos processos, o que faz com que os resultados de checkpoint produzidos no sejam totalmente consistentes.
Existe tambm um grande nmero de solues que propem a realizao de checkpoints e migrao de processos atravs de abordagens orientadas a objetos. Dentro dessa
classe de soluo podemos citar Abacus (AMIRI et al., 1999), Emerald (OCONNOR,
55
2009), Globus (FOSTER; KESSELMAN, 1996), Legion (GRIMSHAW et al., 1997) e

Rover (JOSEPH et al., 1997). Esses sistemas so usualmente definidos e projetados como
middlewares ou at mesmo como linguagens de programao especficas, o que requer
aes explcitas do programador para controlar e realizar as operaes de checkpoint e
migrao.
Kasbekar et al (KASBEKAR et al., 1999) apresentam um mecanismo para realizar
checkpoints seletivos em aplicaes orientadas a objetos que possuam threads independentes. No modelo proposto pelos autores, um sub-sistema criado e nele mantido,
de maneira centralizada, um grafo de dependncia que oferece informaes referentes s
threads envolvidas e os objetos que so acessados por cada uma das threads. Esse grafo
percorrido, no momento em que a ao de checkpoint realizada, para identificar qual
o conjunto de threads, e seus respectivos objetos, que devem ser includos no checkpoint.
O modelo lida com falhas de maneira individual a cada thread; quando uma thread falha,
somente ela e os objetos envolvidos no seu processamento so consideradas para o processo de roll-back, sendo que as demais threads continuam o processamento normal de
execuo. Essa abordagem faz com que cada thread tenha que atualizar constantemente
seu estado de execuo no grafo.
3.7
Consideraes Finais
Este captulo introduziu e detalhou alguns dos principais mecanismos de checkpoint

disponveis. Foram apresentadas as solues existentes para as principais plataformas de
computao voluntria. Nesse tipo de ambiente, os mecanismos de checkpoint so fundamentais para permitir o armazenamento e recuperao de resultados intermedirios produzidos pelos recursos voluntrios. Tambm foram apresentadas solues de checkpoint
que se apresentam como solues para tolerncia a falhas. Dentre essas propostas, foram
detalhadas as solues que fazem uso de bibliotecas extras acopladas aplicao-alvo,
implementaes que utilizam recursos do sistema operacional, alm de outras solues
para checkpoint que propem modificaes nas mquinas virtuais.
O mecanismo de checkpoint que detalhado nessa dissertao, oferece uma proposta
de soluo que pode ser comparada a alguns dos mecanismos aqui apresentados. O modelo proposto faz uso de pequenas modificaes na aplicao em que se deseja executar no
ambiente voluntrio. Apesar de ser necessria essa pequena modificao, no se faz necessrio realizar nenhuma modificao invasiva em termos de sistema operacional, nem
mesmo necessidades especiais para compilar a aplicao. Ao classificarmos o modelo
proposto por essa dissertao, correto defini-lo como uma soluo realizada em nvel de
usurio, sem modificaes ou alteraes no sistema operacional ou mquina virtual.
56
DISKLESS CHECKPOINT
Mecanismos de Checkpoint operam atravs do armazenamento das informaes necessrias para a retomada de execuo de um processo ou programa. Abordagens de
checkpoint baseadas em disco armazenam esses dados em meios de armazenamento estveis, como discos. Essa operao de armazenamento se apresenta, na maioria das vezes,
como um gargalo de execuo para os ambientes distribudos, em termos de performance.
Isso ainda mais grave em ambientes distribudos que possuem mais processadores do
que disco, pois a disputa pela escrita, por parte dos processadores, mais intensa, gerando
um aumento ainda maior na performance para execuo do checkpoint (SILVA; SILVA,
1998a; PLANK et al., 1998a; BOWMANM, 2006).
Esse custo elevado, associado com os gargalos de desempenho para execuo acarreta
um elevado custo para essa abordagem, o que limita a quantidade de checkpoints que
podem ser executados. Alm disso, o armazenamento das informaes em disco acarreta
um overhead de rede e disco que fazem com que o processamento normal da aplicao
de interesse aumente em termos de tempo (SILVA; SILVA, 1998a; PLANK et al., 1998a;
BOWMANM, 2006).
O presente captulo mostra uma abordagem para realizao de checkpoints que utiliza
recursos volteis, como memria, para armazenamento das informaes intermedirias
produzidas. Alm de apresentar, conceitualmente, a abordagem de diskless checkpoint,
so mostradas as principais abordagens utilizadas dentro desse conceito.
4.1
Fundamentao Terica
O objetivo principal do diskless checkpoint tornar o processamento mais rpido,

eliminar o mencionado overhead de rede e reduzir o tempo para armazenamento das informaes atravs da utilizao, de maneira eficiente, da memria disponvel (SILVA;
SILVA, 1998a; PLANK et al., 1998a; BOWMANM, 2006). Diskless Checkpoint pode
ser definido como uma tcnica para armazenar o estado de um processo de longa durao
em um ambiente distribudo sem o armazenamento de informaes em meios estveis
(DONGARRA et al., 2008). Com essa abordagem, cada processador envolvido no processamento armazena uma cpia do seu estado localmente, na maioria das vezes, em
memria. Dessa forma, em caso de ocorrncia de falhas, cada processador capaz de
utilizar as informaes armazenadas e recuperar a sua execuo a partir do ltimo ponto
estvel armazenado. Atravs da no utilizao de meios estveis, como disco rgido, essa
abordagem de checkpoint remove o principal overhead dos mecanismos de checkpoint
tradicionais em sistemas distribudos (PLANK et al., 1998a).
Diskless Checkpointing uma abordagem atrativa que oferece meios confiveis e
de alto-desempenho para armazenamento de informaes (LU, 2005). Nesse modelo,
57
Figura 4.1: Estrutura de Diskless Checkpoint para grandes sistemas

o checkpoint inicialmente escrito em memria, que muito mais rpido que a escrita
em disco. Para garantir a integridade dos dados armazenados, cdigos de redudncia (bits
de paridade ou cdigos Reed-Solomon so calculados e armazenados em processadores
reservas). Esses processadores extra tambm assumem o papel de nodos computacionais
se o processador que acusou uma determinada falha no consiga recuperar seu estado estvel para reiniciar o processamento normal em um curto perodo de tempo - essa situao
acontece tipicamente em casos de falhas de hardware (PATTERSON et al., 1988). Sistemas de grande porte que utilizam o mecanismo de checkpoint em memria, tendem a se
organizar de modo particionado e em pequenos grupos. Cada pequeno grupo formado
ento capaz de cuidar dos seus clculos para redundncia e de suas recuperaes em caso
de falhas. A figura 4.1 representa graficamente a organizao de um sistema de grande
porte que utilize diskless checkpoint como mecanismo para persistncia das informaes
em caso de falhas. Nesse exemplo, os nodos computacionais so particionados em cinco
grupos distintos onde, para cada grupo, existe a presena de um nodo extra. Os dados de
checkpoint produzidos so escritos em memria local e as informaes de redundncia
so calculadas e armazenadas no nodo extra.
Para tornar a abordagem de diskless checkpoint a mais eficiente possvel, ela pode
ser implementada em nvel de aplicao, ao invs de ser utilizada em nvel de sistema
(JAMES S. PLANK YOUNGBAE KIM, 1997). De acordo com (DONGARRA et al.,
2008), entre as vantagens de utilizar um mecanismo de checkpoint em nvel de aplicao,
pode-se destacar:
Checkpointing em nvel de aplicao pode ser configurado e disponibilizado em
pontos especficos de sincronizao no programa, atingindo, de maneira automtica, checkpoints consistentes;
O tamanho do checkpoint (em termos de memria) pode ser minimizado pois os desenvolvedores da aplicao podem restringir os dados a serem persistidos de acordo
com as necessidades especficas;
Checkpoints realizados em nvel de aplicao podem ser implementados de modo
que a operao de recuperao do estado consistente pode ser realizado em ambientes heterogneos.
A idia de substituir a mdia magntica por memria como mecanismo preferido para
armazenamento tem suas origens na dcada de 80. Mas somente tornou-se efetivamente
58
utilizada nos dias atuais graas diminuio considervel dos preos desse tipo de recurso, bem como com a ampla adoo dessa tecnologia em dispositivos mveis como
cmeras digitais, PDAs, pendrives e cartes de memria flash.
Operaes de IO sempre se apresentaram como fatores crticos, fazendo com que pesquisadores, desde a dcada de 80, pensem em solues para armazenar todas as informaes das bases de dados em memria (GARCIA-MOLINA; SALEM, 1992). Entretanto, a
utilizao de discos rgidos no pode ser descartada e os dados ou as informaes de logs
transacionais devem ser persistidos em meio fsico. Outro fator que se apresenta como
limitante para a ampla utilizao de memria voltil como meio de armazenamento era
o preo da mesma: apenas algumas poucas aplicaes de telecomunicaes e outras de
tempo real ofereciam uma quantidade suficiente para o armazenamento de todos os dados
e informaes.
No contexto de sistemas operacionais, muitos trabalhos foram desenvolvidos em sistemas in-memory. Non-volatile RAM (NVRAM) tem sido empregada em diversas solues
para mitigar o trfego de escrita gerado pelas aplicaes, bem como para oferecer maior
confiabilidade e segurana (BAKER et al., 1992; WU; ZWAENEPOEL, 1994; CHEN
et al., 1996; WANG et al., 2002).
Dispositivos mveis tambm fazem uso de sistemas gerenciadores de arquivos em
disco. Como exemplo, memria flash um tipo de NVRAM que amplamente utilizado
em hand-helds. A latncia de acesso nesse tipo de dispositivo mais lento que DRAM,
especialmente para operaes de escrita. Isso se deve pelo fato de que o contedo precisa
ser apagado antes que novas informaes possam ser escritas. Esse processo de limpeza
deve ser executado de maneira block-wise e leva, em mdia, aproximadamente 0.6 a 0.8
segundos por bloco. Como resultado, esse tipo de sistema baseado em memria flash
deve fazer uso de algoritmos e tcnicas para substituio de blocos. Como exemplos de
sistemas desse tipo, as solues (WU; ZWAENEPOEL, 1994; KAWAGUCHI et al., 1995)
podem ser citadas.
Semelhante aos sistemas de arquivos em memria, a utilizao de discos RAM, que
suportada por diversos sistemas operacionais (TANENBAUM, 2007). Um disco RAM
pode ser definido como uma poro pr-alocada da memria principal que simula um
disco fsico tradicional. Essa soluo usualmente implementada atravs de um programa
residente em memria ou um driver de kernel do sistema operacional. Discos RAM so
normalmente utilizados para armazenar dados intermedirios que sero descartados em
curtos espaos de tempo, como, por exemplo, arquivos temporrios.
Tendo esse conceito definido, Diskless Checkpointing pode ser pensado como uma organizao RAID de um grupo de discos RAM. Dentre os vrios trabalhos desenvolvidos
dentro dessa abordagem, Veer et al, em (SILVA et al., 1994) implementou uma soluo
de checkpoint espelhado em redes Transputer, onde as informaes de checkpoint so
armazenadas em nodos vizinhos, que se apresentam como recursos parceiros para armazenamento das informaes, como forma de backup. Plank (PLANK; LI, 1994a) props
a utilizao de cdigos de redundncia para melhorar a recuperao de nodos de execuo que venham a sofrer falhas. Chiueh (CHIUEH; DENG, 1996a) realizou testes em
ambientes de checkpoint espelhados e com informaes de paridade em mquinas massivamente paralelas e obteve resultados que mostraram que o espelhamento torna a soluo
at dez vezes mais rpida, com um custo de cerca de duas vezes mais memria. Plank,
em (PLANK et al., 1998a), estende a abordagem de paridade para utilizar Reed-Solomon
para suportar falhar arbitrrias.
Em tempos recentes, a utilizao de mecanismos para checkpoint em memria volta-
59
ram a despertar interesse em pesquisadores ao redor do mundo. Em (CHEN et al., 1994),

os autores utilizaram checkpoint com espelhamento em conjunto com uma biblioteca MPI
tolerante a falhas para oferecer maior confiabilidade na execuo de programas paralelos.
Zheng (ZHENG et al., 2004) modificou o conceito de espelhamento atravs do armazenamento das informaes de checkpoint em dois nodos diferentes, com dedicao exclusiva,
fazendo que a resistncia a falhas mltiplas fosse aumentado. Em (SUNDERAM et al.,
2004), Chen tambm estudou uma nova classe de cdigos de redundncia, onde as informaes so tratadas como um stream de bits sem considerar informaes semnticas.
Na abordagem de Chen, os cdigos de redundncia so definidos sobre nmeros reais ou
nmeros complexos.
importante destacar que as abordagens de diskless checkpoint no se apresentam
como uma soluo que substitui os mecanismos de checkpoint tradicionais: ela serve
como um complemento. A implementao de uma soluo de checkpoint em memria,
segundo (PLANK et al., 1998a) til para armazenamento de informaes intermedirias
produzidas ou dados temporrios. Essa abordagem oferece uma maneira rpida de armazenamento, para quando as informaes a serem armazenadas mudam com freqncia.
O presente captulo apresenta os principais esquemas de checkpoint em memria que
podem ser utilizados sem nenhuma modificao de hardware: neighbor-based, paritybased, checksum-Based, weighted-checksum-based, parity-based e encoding.
4.2
Neighbor-Based Checkpointing
Em mecanismos de checkpoint baseados em vizinhos (do ingls neighbor-based),

cada processador do modelo de computao participa de um ambiente onde um processador definido e eleito como vizinho. Nessa abordagem, alm de manter as informaes em sua memria, cada processador armazena uma cpia das informaes de seu
checkpoint no processador vizinho. Dessa forma, quando falhas acontecem para um determinado processador, as informaes de checkpoint, que sero utilizadas para retomar a
execuo, podem ser buscadas na memria do processador vizinho.
O overhead de desempenho da execuo de diskless checkpoint usualmente muito
baixo. O checkpoint armazenado somente em dois lugares: no processador original,
onde o processamento est sendo realizado e no processador vizinho, que serve como
um local de armazenamento de backup. A recuperao das informaes envolve somente
os processadores envolvidos na falha e seus vizinhos. No existem comunicaes globais entre todos os processadores do ambiente, nem mesmo so necessrios clculos para
codificao e decodificao das informaes armazenadas no checkpoint.
Baseado em como o processador vizinho eleito, a abordagem de neighbor-based
checkpointing pode se estabelecer de acordo com trs esquemas distintos: mirroring, Ring
Neighbor e Pair Neighbor (DONGARRA et al., 2008).
4.2.1
Mirroring
O esquema de espelhamento, do mecanismo de checkpoint baseado em utilizao de

vizinhos, foi originalmente proposto em (PLANK et al., 1998a). Nesse esquema, supondo a existncia de n processadores disponveis e dedicados para computao, outros
n processadores devem ser alocados e dedicados exclusivamente para participarem como
vizinhos. Com essa abordagem, o i-simo processador armazena uma cpia das suas informaes de checkpoint no i-simo processador de resguarde que foi alocado para atuar
como vizinho.
60
Figura 4.2: Esquemas de checkpoint baseado em vizinhos

A figura 4.2(a) apresenta um modelo de grafo que demonstra o esquema de espelhamento: cada processador P1 possui um processador vizinho C1 dedicado exclusivamente
para manter as informaes de checkpoint produzidas.
O modelo apresentado est projetado para suportar at n falhas de processadores (onde
n o nmero de processadores disponveis no modelo). Entretanto, a soluo no consegue ser tolerante a falhas em casos onde ocorra um erro simultneo no processador e seu
vizinho. Se as premissas que estabelecem que as falhas de cada processador so independentes (isto , no ocorrem simultaneamente no processador e no seu vizinho eleito) e que
as falhas so distribudas de maneira idntica forem verdadeiras, a probabilidade de que o
modelo de espelhamento se comporte dentro do esperado para falhas em k processadores
pode ser estabelecida pela seguinte equao:
Cnk 2k
k
C2n
Quando o nmero de falhas k for significativamente menor que o nmero de processadores n, a probabilidade de que o modelo se comporte bem a k falhas muito prximo
de 1. A principal desvantagem que se observa nesse modelo de espelhamento a necessidade da existncia de n processadores adicionais que devem ser dedicados exclusivamente
para o armazenamento das cpias de checkpoint, tornando-os, portanto, recursos que no
podem ser utilizados para computao e produo de resultados.
4.2.2
Ring Neighbor
Em (SILVA; SILVA, 1998b), o esquema de vizinhana em anel foi discutido por Silva
et al. Nesse modelo, no existe a necessidade de uso de processadores adicionais para a
manuteno de cpias de segurana dos checkpoints produzidos. Os processadores participantes do modelo de computao so armazenados em forma de um anel virtual, como
demonstra a figura 4.2(b).
Cada processador envia uma cpia das suas informaes de checkpoint para o processador que o segue no anel virtual. Dessa forma, cada processador participante tem,
em memria, informaes referentes a dois checkpoints: o seu checkpoint local, com as
informaes produzidas localmente, alm das informaes de checkpoint produzidas pelo
seu vizinho no anel.
Esse modelo de vizinhana em anel capaz de tolerar uma variao de 1 at b n2 c
falhas de processadores, em um ambiente composto de n processadores, dependendo de
61
como a distribuio das falhas dentro do anel. Se comparado com o modelo de espelhamento, a vantagem de organizar a soluo em anel que no se faz necessria a utilizao
de processadores redundantes para armazenamento das cpias de segurana. Entretanto,
como desvantagem, podemos citar que no modelo em anel, cada processador participante
precisa armazenar duas cpias de checkpoints em memria, fato que pode prejudicar,
mesmo que pouco, a capacidade de processamento e armazenamento dos processadores
envolvidos.
4.2.3
Pair Neighbor
Outra abordagem para os mecanismos de checkpoint baseado na utilizao de vizinhos o da vizinhana pareada. Nesse modelo, os processadores participantes do modelo
computacional devem ser organizados em duplas (para esse modelo, deve-se assumir que
exista um nmero par de processadores participantes). Dessa forma, os dois processadores do par estabelecido so vizinhos entre si, e cada processador envia uma cpia das suas
informaes de checkpoint para o outro, como mostra a figura 4.2(c).
Da mesma forma que a abordagem em anel, nesse modelo no existe a necessidade
da utilizao de processadores redundantes e cada processador possui, em memria, informaes referentes ao seu checkpoint local e tambm informaes de checkpoint do
processador pareado. Entretanto, se comparado com o esquema de vizinhana em anel,
o grau de tolerncia a eventuais falhas desse modelo melhor. Assim como o modelo
de espelhamento, se assumirmos que a falha ocorra de maneira independente e identicamente distribuda, isto , no ocorra para ambos processadores de um mesmo par, a
probabilidade de que o modelo resista a k falhas em um modelo computacional com n
processadores :
C kn 2k
2
k
C2n
4.3
Parity-Based Checkpointing
A execuo de checkpoints atravs de mecanismos de paridade consiste basicamente

de duas etapas: cada processador executa um checkpoint das informaes em memria
local e, em uma segunda etapa, realiza a codificao dessas informaes armazenandoas em um processador dedicado para armazenar as informaes de encoding de todos os
processadores participantes do ambiente de processamento (HUNG, 1998).
Em caso de ocorrncia de falhas em algum dos processadores envolvidos, todos os
processadores do ambiente computacional em questo, que no estiverem envolvidos na
falha, executam uma ao de rollback utilizando como estado consistente a informao
de checkpoint existente em suas memrias locais. A partir dessa recuperao, um processador Pi qualquer utilizado como substituto do processador que apresentou falhas e este
executa uma ao de rollback utilizando a informao calculada a partir dos dados dos
processadores funcionais e da informao de encoding do processador dedicado.
Essa abordagem para execuo de checkpoint pode ser feita atravs de checkpoint
local, checkpoint atravs de encoding ou da combinao das duas abordagens. As sees
seguintes detalham essas possibilidades.
62
4.3.1
Local Checkpointing
Como o nome sugere, essa abordagem de checkpoint local determina que os processadores envolvidos devam realizar o armazenamento de suas informaes especficas de
checkpoint em memria local. Alm disso, por se tratar de uma abordagem diskless, no
existe a necessidade de armazenamento em disco. Essa abordagem pode ser implementada de trs maneiras distintas: simples, incremental e forked.
4.3.1.1
Simple Checkpointing
A forma mais simples para realizao de checkpoint atravs da manuteno de uma

cpia local em memria do espao de endereos e dos registradores. Nessa forma mais
simples de diskless checkpoint, se a execuo de uma operao de rollback necessria,
as informaes dos endereos e registradores, mantidas em memria, so recuperadas e
aplicadas ao processador, possibilitando o retorno a um estado de execuo consistente.
importante que seja destacado que essa abordagem no oferece tolerncia a falhas
no prprio processador. Isso significa que o processador que apresentar qualquer falha de
execuo no ser capaz de recuperar seu prprio estado a partir do ltimo checkpoint,
pois no ter mais as informaes disponveis em memria. Essa abordagem somente
vlida para permitir que um processador execute as operaes de rollback para as ltimas
informaes consistentes armazenadas em caso de falhas de outros processadores.
O principal problema dessa abordagem a quantidade de memria necessria para
sua correta implementao. Pra que seja possvel realizar a recuperao completa das
informaes e recuperar a correta execuo no ambiente computacional, cada processador
participante deve manter, em sua memria local, uma cpia de toda a aplicao (PLANK
et al., 1998b; HUNG, 1998).
4.3.1.2
Incremental Checkpointing
Nssa abordagem, o mecanismo de proteo de pginas de memria do sistema operacional utilizado para observar, em tempo de execuo do checkpoint, quais pginas
de memria sofreram modificaes desde o ltimo checkpoint. As informaes identificadas atravs desse processo so, portanto, as informaes que devem ser armazenadas.
Para identificar os dados que foram modificados, existem duas classes de tcnicas que
podem ser utilizadas: baseada em pginas e baseadas em hash. Para a primeira tcnica,
necessrio disponibilidade de memria e suporte do sistema operacional para a manipulao dos bits de proteo a fim de identificar as pginas de memria modificadas. Na
segunda tcnica, a memria particionada em blocos e uma funo de hash executada
sobre cada um dos blocos. A partir das informaes geradas pela execuo da funo,
possvel encontrar os blocos modificados.
Entretanto, essa abordagem incremental apresenta um problema relacionado quantidade de informaes desatualizadas que deve ser mantida em memria. Em abordagens
de checkpoint no-incrementais, apenas as informaes de checkpoint mais recentes devem ser mantidas para possibilitar a recuperao das informaes, ou seja, informaes
mais antigas podem ser descartadas. Em contraponto, em abordagens incrementais, as
informaes antigas de checkpoint no podem ser descartadas pois as informaes das
pginas de memria so distribudas e espalhadas por diversos checkpoints. Dessa forma,
o tamanho cumulativo das informaes de checkpoint incremental tende a crescer a medida do tempo, j que vrios valores atualizados podem ser armazenados para uma mesma
pgina de memria (PLANK et al., 1995)
63
Figura 4.3: Esquema de Paridade RAID nvel 5

4.3.1.3
Forked Checkpoiting
Essa implementao de checkpoint realizada atravs de um mecanismo de clonagem

de processo, como por exemplo, a chamada de sistema fork existente em sistemas Unix.
O processo clonado, resultante da execuo dessa chamada de sistema funcionar como
o diskless checkpoint. Essa informao , portanto, armazenada em memria e tem sua
principal utilidade para que os processadores que no apresentarem falhas ou erros de execuo possam realizar um rollback e retomar o seu estado consistente aps a ocorrncia
de falhas em outros processadores (PLANK et al., 1998b; HUNG, 1998).
Esse modelo funcional para que todos os processadores participantes do ambiente
computacional possam realizar operaes de rollback e estejam aptos a recuperar um
estado consistente de execuo. Entretanto, no se apresenta como uma soluo tolerante
a falhas para o prprio processador que apresenta o erro. Isto significa que no uma
soluo tolerante a falhas para o prprio processador em estado consistente (PLANK
et al., 1998b; HUNG, 1998).
4.3.2
Encoding Checkpointing
Atravs de mecanismos de checkpointing que faam uso de alguma abordagem de

codificao, um nmero m de processadores extra so utilizados de maneira dedicada
para a realizao dessa codificao. Esses processadores so utilizados para realizar a
codificao dos checkpoints para todos os processadores participantes do ambiente computacional alm de serem teis para recuperao dessas informaes, que servem para
que os processadores que venham a falhar possam ter seu estado consistente re-calculado
e recuperado. Existe um grande nmero de abordagens de codificao para checkpoint,
dentre elas podemos citar paridade (RAID nvel 5) e Reed-Solomon que so apresentadas
em detalhes abaixo.
4.3.2.1
Parity (RAID nvel 5)
Sendo F o tempo mdio que antecede uma falha em um equipamento qualquer, ento o tempo mdio para que uma falha qualquer ocorra em um ambiente computacional
com n equipamentos Fn . Para ambientes computacionais com valores de n pequenos e
com equipamentos razoavelmente confiveis, a utilizao de apenas um processador dedicado para a execuo de checksums suficiente para oferecer uma boa tolerncia a falhas
(PATTERSON et al., 1988; GIBSON, 1992; CHEN et al., 1994). A essa configurao de
ambiente (que pode ser representado graficamente atravs da figura 4.3) dado o nome
de RAID de nvel 5 e a tcnica de codificao utilizada chamada de paridade de n + 1.
Nessa abordagem de codificao existe um processador dedicado para checkpoint
m = 1 que responsvel por codificar a paridade para cada checkpoint da aplicao.
Sendo bji o byte que representa o j-simo byte do processador i, ento o j-simo byte do
64
processador de checkpoint ser:

bjckp = bj1 bj2 . . . bjn
Em caso de ocorrncia de falhas, de acordo com (PLANK et al., 1998b), o estado
consistente de execuo pode ser recuperado da seguinte forma: um processador substituto qualquer deve ser eleito para assumir o lugar de processamento do que apresentou
falha. Esse novo processador pode ser o processador responsvel por checkpoint, um
processador extra que estava alocado como reserva ou at mesmo o prprio processador
que inicialmente havia falhado, caso seja uma ocorrncia de falha transiente. Esse novo
processador calcula ento a informao de checkpoint do processador falho atravs da
utilizao das informaes de paridade dos processadores que no sofreram falhas e do
encoding existente no processador de checkpoint. Em representao matemtica, suponha
que o processador i sofra uma falha qualquer, o checkpoint pode ento ser reconstrudo
com:
bji = bji . . . bji1 bji+1 . . . bjn bjckp
Quando o processador substitudo finalizou o clculo do checkpoint do processador
que falhou, todos os processadores da aplicao esto aptos a realizar a operao de rollback no ltimo checkpoint e o processamento computacional pode seguir a partir das
informaes recuperadas.
4.3.2.2
Reed-Solomon
Em 1960, Irving Reed e Gus Solomon publicaram um artigo no Journal of the Society
for Industrial and Applied Mathematics, (REED; SOLOMON, 1960), descrevendo um
novo modelo de codificao para correo de cdigos, chamado de Reed-Solomon. Essa
soluo tem uma grande utilidade, sendo utilizada em diversas aplicaes atualmente,
desde disc players at aplicaes mais complexas. Reed-Solomon, doravante chamados
R-S, so cdigos no-binrios cclicos com smbolos, formado por seqncias de m bits,
onde m um nmero inteiro positivo qualquer, maior ou igual a 2.
Cdigos R S(n, k) para smbolos m-bit existem para todo n e k onde
0 < k < n < 2m + 2
onde k representa os smbolos de dados que esto sendo codificados e n o nmero
total de smbolos do bloco. Para a codificao mais convencional de R S(n, k), tem-se:
(n, k) = (2m 1, 2m 1 2t)
onde t a capacidade de correo de erros do smbolo e n k = 2t representa o
nmero de smbolos de paridade do modelo. Uma verso estendida do cdigo R-S pode
ser criada com, no mximo, n = 2m ou n = 2m + 1.
Em cdigos R-S, para seqncias de informaes no-binrias, a distncia entre duas
palavras codificadas definida como o nmero de smbolos onde as seqncias se diferem. Para cdigos R-S, a distncia mnima, de acordo com (GALLAGER, 1968) :
dmin = n k + 1
65
Essa codificao capaz de proporcionar, de acordo com os autores de (SKLAR,

1988), a correo de qualquer combinao de t (ou menos) erros, onde t pode ser expresso
por:
t=d
dmin 1
nk
e=d
e
2
2
A equao acima ilustra o fato de que, para cdigos R-S, para a correo de t erros
no so necessrios mais do que 2t smbolos de paridade.
4.3.3
Integrao de Local e Encoding Checkpointings
Um dos fatores mais importantes para mecanismos de checkpoint o desempenho,

em termos de tempo de execuo (CHIUEH; DENG, 1996b; SILVA; SILVA, 1999). O
overhead, nas abordagens de integrao de local e encoding checkpointings, surge nas
atividades de clculo e envio das informaes calculadas.
Em alguns mecanismos de codificao mencionados aqui, existe um gargalo pois os
processadores destinados a execuo de checkpoints so alvos de uma srie de mensagens, enviadas por todos os processadores participantes do ambiente computacional.
Alm desse gargalo em termos da quantidade de mensagens recebidas, esses processadores so responsveis por todo o clculo de codificao. Para mitigar esses gargalos e
melhorar um pouco o desempenho, uma soluo a utilizao de um mtodo FAN-IN1 .
Nessa abordagem, os processadores do ambiente computacional realizam os clculos de
encoding em log n passos e enviam o resultado final para os processadores de checkpoint.
Outra abordagem para mitigar o tempo de execuo, melhorar o desempenho e reduzir a comunicao na rede reduzir o tamanho das mensagens trocadas. Atravs da
utilizao de uma abordagem semelhante ao checkpoint incremental, apenas as pginas
de memria modificadas desde o ltimo checkpoint so enviadas para os processadores.
Essas mudanas, chamadas de diff, so enviadas aos processadores de checkpoint que realiza uma operao de XOR com as informaes j existentes. Ainda, o mtodo pode ser
melhorado atravs da compresso das informaes de diff antes do envio da mensagem
(HUNG, 1998).
4.4
Checksum-Based Checkpointing
O checkpoint baseado em checksums uma verso modificada do mecanismo de

checkpoint baseado em paridade (apresentado anteriormente, nesse mesmo captulo) proposto e apresentado em (PLANK; LI, 1994b). Nesse modelo, ao invs da utilizao de
paridade, uma proposta de adio numrica de pontos-flutuantes utilizada para codificar todas as informaes dos dados do checkpoint local. Atravs do envio das informaes codificadas aos processadores dedicados para checkpoints, essa proposta adiciona
um overhead de memria muito menor ao modelo computacional, se comparado com
o mecanismo de checkpoint baseado em vizinhos. Entretanto, as atividades de clculo
e envio das informaes codificadas introduzem um overhead de desempenho maior, se
comparado ao mesmo esquema. De acordo com o modo como o clculo do encoding
realizado, o modelo de checkpoint baseado em checksum pode ser definido em duas
categorias: esquema de checksum bsico e esquema de checksum de uma dimenso.
1
FAN-IN pode ser definido como o nmero de entradas padro de uma determinada entrada lgica.
66
Figura 4.4: Esquema baseado em checksum

4.4.1
Esquema baseado em Soma de Verificao Bsico
No esquema de soma de verificao bsico, do ingls basic checksum, supondo a

existncia de um programa sendo executado em um ambiente computacional com N processadores disponveis, necessria a existncia de um processador de ordem N + 1, denominado processador de checksums. Durante toda a atividade computacional do modelo
em questo, informaes de checkpoint consistentes so mantidas, em memria, pelos N
processadores participantes. Alm disso, a soma de verificao das informaes de checkpoint para os N processadores mantida no processador de checksums, como mostra a
figura 4.4:
Assumindo como verdade as premissas que estabelecem que Pi a informao de
checkpoint do processador de ordem i e que C a soma de verificao do checkpoint local
no processador de checksums, se olharmos os dados de checkpoint produzidos como sendo
um array de nmeros reais, ento a codificao do checkpoint estabelece a identidade
P1 + . . . + Pn = C
entre os dados do checkpoint do processador Pi e a soma de verificao C no processador de checksums. Em caso de ocorrncia de uma falha em qualquer um dos processadores Pn , a identidade estabelecida acima se torna em uma equao com um termo
desconhecido. Desse modo, atravs da resoluo da equao, possvel reconstruir as
informaes faltantes.
Devido as operaes aritmticas de ponto flutuante utilizadas nos mecanismos de
checkpoint e recovery, podem ocorrer erros de arredondamento, onde o valor calculado
aproximado difere do valor real matemtico. Embora esse problema esteja presente, ele
pode ser considerado praticamente nulo, de acordo com (PLANK; LI, 1994b), pois a codificao dos dados do checkpoint envolve apenas operaes de adio e a decodificao
envolve apenas adio e subtrao.
O esquema baseado em soma de verificao bsico consegue lidar com apenas uma
falha. Caso duas ou mais falhas ocorram, a identidade acima passa a ter mais de um
termo desconhecido, fazendo com que sua soluo no seja possvel, o que torna o sistema
impossvel de ser recuperado. Entretanto, esse princpio bsico de recuperao atravs de
checksum pode ser utilizado para construir mecanismos mais elaborados, como o esquema
de uma dimenso, que permite que a soluo sobreviva a mltiplas falhas.
4.4.2
Modelo de checksum de Uma Dimenso
Supondo que um determinado programa est sendo executado em um ambiente computacional com mn processadores disponveis, o modelo sugere que o ambiente seja particionado em m grupos com n processadores em cada um, tendo um processador de check-
67
Figura 4.5: Esquema de Checksum de Uma Dimenso

sum dedicado para cada grupo. Nesse esquema, representado pela figura 4.5, para cada
grupo, a soma de verificao deve ser calculada conforme descrito no esquema simples,
apresentado acima.
A vantagem desse modelo, segundo (DONGARRA et al., 2008), que os checkpoints
so realizados em um subgrupo especfico de processadores, de modo que a codificao
das informaes, para cada grupo, possa ser realizada em paralelo. Se comparado com
o modelo bsico de soma de verificao, o desempenho desse esquema usualmente
melhor.
Se assumirmos como verdadeiras as premissas que estabelecem que as falhas sejam
independentes e identicamente distribudas, a probabilidade de que o esquema de verificao de soma de uma dimenso permanea funcional em caso de k(k < m) falhas
k
Cm
(n + 1)k
k
Cm(n+1)
4.4.3
Modelo de checksum de Duas Dimenses
O modelo de checksum de duas dimenses, representado pela figura 4.6 uma extenso do modelo de checksum de uma dimenso. Nessa abordagem, os processadores
participantes do modelo so organizados logicamente em um grid de duas dimenses,
com a presena de um processador para checkpoint em cada coluna e linha do grid. Cada
um dos processadores de checkpoint ento responsvel por realizar o encoding dos processadores
da sua linha ou coluna. O modelo de paridade em duas dimenses necessita
de m n processadores de checkpoint, fazendo com que esse esquema esteja apto a
suportar falhas de um processador Pn qualquer, para uma determinada linha ou coluna da
matriz.
4.5
Checkpoint baseado em Weighted-Checksum
De acordo com (DONGARRA et al., 2008), o modelo de soma de verificao com

utilizao de pesos uma extenso do esquema de checkpoint baseado em checksum
apresentando anteriormente, com o diferencial de estar apto a responder, de maneira consistente, a falhas mltiplas que possam ocorrer em diversos padres, utilizando para isso
um nmero mnimo de processadores para redundncia (processadores dedicados exclusivamente para armazenamento de informaes de checkpoint). De acordo com (PLANK,
1997), essa abordagem tambm pode ser interpretada como uma implementao do esquema de codificao Reed-Solomon no campo de nmeros reais.
68
Figura 4.6: Esquema de Checksum de Duas Dimenses
Figura 4.7: Modelo Bsico de Weighted Checksum

Nessa abordagem, cada processador participante do ambiente de computao mantm, em memria local, uma cpia das informaes de checkpoint. Alm disso, so estabelecidas m equaes de igualdade, atravs do armazenamento dos pesos associados ao
checkpoint local para os m processadores. Desse modo, quando ocorrem f falhas, onde
f m, as m igualdades se transformam em m equaes com f termos desconhecidos.
Atravs da escolha correta dos pesos, possvel recuperar os dados perdidos nas f falhas
atravs da resoluo das m equaes geradas.
4.5.1
The Basic Weighted Checksum Scheme
Para definir o modelo bsico de checksum com pesos associados, supe-se a existncia
de n processadores utilizados para a produo de resultados no ambiente computacional
e assume-se que as informaes de checkpoint produzidas pelo i-simo processador Pi .
Para ser possvel reconstruir os dados perdidos nos processadores que acusaram falhas,
necessrio que outros m processadores sejam dedicados para manter m somas de verificaes com pesos associados (weighted checksums) dos dados de checkpoint, como
apresentado na figura 4.7. Dessa forma, a soma de verificao com peso associado Pj no
j-simo processador de checksums pode ser calculada atravs da frmula:
a11 P1 + . . . + a1n Pn
= C1
..
.
am1 P1 + . . . + amn Pn
= Cm
onde ai j, i = 1, 2, . . . , mj = 1, 2, . . . , n representa o peso que deve ser escolhido.

Sendo definido que A = (aij mn ) a matriz do modelo de checksum com pesos associados.
69
Supondo que k processadores participantes do modelo de computao e m h processadores destinados a operaes de checkpoint entraram em um estado de falha, ento
n k processadores de computao e h processadores de checkpoint sobreviveram s
falhas. Se avaliarmos as informaes dos processadores que apresentaram falhas como
termos desconhecidos, a partir da equao acima, teremos m equaes com m (h k)
termos desconhecidos.
Se k > h, ento teremos menos equaes geradas do que termos desconhecidos,
fazendo com que se tenha mais de uma soluo possvel o que, por consequencia, no
permita a recuperao dos processadores com falhas. Entretanto, se k < h, teremos
mais equaes do que termos desconhecidos. Se a matriz A for corretamente definida,
uma soluo nica para a equao acima pode ser encontrada e as informaes perdidas
pelos processadores que acusaram falhas podem ser recuperadas atravs da resoluo das
equaes.
Em termos gerais, se tomarmos como verdadeiras as premissas:
Os processadores j1 , j2 , . . . , jk participante do modelo computacional falharam e
os processadores jk+1 , jk+2 , . . . , jn permanecem disponveis, sem apresentarem falhas;
Os processadores de checkpoint i1 , i2 , . . . , ih permanecem disponveis sem a ocorrncia de falhas enquanto os processadores de checkpoint ih+1 , ih+2 , . . . , im caram
em decorrncia de falhas.
A partir dessas premissas, a equao acima apresenta Pj1 , . . . , Pjk e Cih+1 , . . . , Ci m
como termos desconhecidos depois da ocorrncia de falhas. Dessa forma, a equao pode
ser re-estruturada, do seguinte modo:
ai1 j1 Pj1 + . . . + ai1 jk Pjk
= Ci1
..
.
Pn
ai1 jt Pjt
aih j1 Pj1 + . . . + aih jk Pjk
= Cih
Pn
aih jt Pjt
t=k+1
t=k+1
Cih+1
Cim
= aih+1 1 P1 + . . . + aih+1 n Pn
..
.
= aim 1 P1 + . . . + aim n Pn
Sendo Ar a matriz de coeficientes do sistema linear exposto pela equao acima. Se

Ar possui um posto completo de colunas2 , ento Pj1 , . . . , Pjk pode ser resolvido atravs
da equao acima e Cih+1 , . . . , Cim pode ser recuperado substituindo Pj 1, . . . , Pj k.
O fato de estar ou no apto a recuperar os dados perdidos nos processadores que
acusaram falhas depende diretamente da matriz Ar possuir ou no um posto completo de
colunas. Entretanto, para a equao apresentada acima, Ar pode ser qualquer sub-matriz
de A, dependendo de como os processadores que acusaram falhas esto distribudos. Se
qualquer sub-matriz quadrada de A e existem mais de m processadores com falhas, ento
garantido que Ar ter um posto completo de coluna. Dessa forma, para estar apto a se
recuperar de at m processadores com falhas, a matriz de checkpoint A deve satisfazer
qualquer sub-matriz quadrada de A.
2
O posto (ou Rank) de uma matriz o nmero de linhas linearmente independentes igual ao nmero de
colunas linearmente independentes. O posto de uma matriz mxn estabelecido por, no mximo, minm, n.
Da matriz que possui o posto maior possvel dito que esta tem um posto completo. Dessa forma, da matriz
mxn que possui um posto igual a n dito que esta possui um posto completo de colunas.
70
Figura 4.8: Esquema de Checksum com Pessos Associados de Uma Dimenso

4.5.2
Two Dimensional Weighted Checksum Scheme
Esse modelo funciona de maneira semelhante ao modelo One Dimensional Checksum Scheme apresentado anteriormente, mas de modo a utilizar pesos associados. Para
entender o esquema de checksum de uma dimenso com pesos associados devemos assumir que o programa est sendo executado em um ambiente computacional com mn
processadores. O particionamento desses processadores deve ser feito em m grupos de n
processadores cada. Alm desse particionamento, outros k processadores devem ser dedicados para clculo de checksum. Nessa configurao, cada grupo realiza operaes de
checkpoint utilizando o modelo bsico de weighted checksum apresentado anteriormente,
gerando um ambiente semelhante ao representado na figura 4.8.
Nessa configurao, o modelo consegue sobreviver a k falhas de processadores em
cada grupo. A vantagem dessa abordagem, segundo (DONGARRA et al., 2008) est no
fato de que o checkpoint localizado em um sub-grupo especfico de processadores, de
modo que o encoding de cada grupo pode ser realizado de maneira paralela por todos
os grupos do ambiente. Ainda segundo (DONGARRA et al., 2008), esse modelo, se
comparado com o modelo bsico de weighted checksum, apresenta ganhos considerveis
de desempenho na execuo.
4.6
Avaliao da Abordagem
A abordagem de checkpoint em memria, se comparada com abordagens mais tradicionais de armazenamento em disco, apresenta algumas vantagens que justificam a sua
utilizao. Entretanto, junto com as vantagens, a abordagem tambm apresenta algumas
limitaes, que devem ser conhecidas e avaliadas para justificar a deciso de sua utilizao
ou no.
4.6.1
Vantagens
A abordagem de realizar checkpoints em memria em detrimento da realizao em

disco, de acordo com (SILVA; SILVA, 1998a; PLANK et al., 1998a; BOWMANM, 2006)
traz uma srie de benefcios, dentre eles:
Latncia e tempo de recuperao da informao reduzidos, se comparada com o
checkpoint tradicional em disco;
Reduz a necessidade de utilizao de recursos compartilhados;
Usa, de maneira eficiente, a memria disponvel para armazenamento das informaes teis para o checkpoint;
71
No necessita adio de recursos de hardware extras para armazenar e realizar o

checkpoint;
Oferece um tempo de execuo do checkpoint inferior, quando comparado com o
checkpoint em disco.
4.6.2
Limitaes
Da mesma forma, a utilizao dessa abordagem tambm pode oferecer algumas limitaes. Ainda de acordo com (SILVA; SILVA, 1998a), (PLANK et al., 1998a) e (BOWMANM, 2006), as principais limitaes que a abordagem de checkpoint em memria
pode trazer so:
Utilizao de encoding, memria, CPU e rede podem trazer pequenos overheads
para a execuo;
Quando utilizado sozinho, o checkpoint em memria no consegue eliminar a ocorrncia de falhas gerais de execuo da mquina, pois o contedo da memria pode
ser eliminado.
Em (BOWMANM, 2006), o autor cita que a abordagem de checkpoint em memria
possui uma cobertura de falhas relativamente inferior, se comparada com o checkpoint em
disco, j que nenhum dos componentes de um ambiente de diskless-checkpoint consegue
sobreviver a uma falha genrica de execuo, onde o recurso computacional deva ser
desligado e reiniciado.
4.7
Consideraes Finais
Nesse captulo, foram apresentados os principais conceitos relacionados a checkpoint

em memria, que no fazem uso de modificaes de hardware. Nesse contexto, foram
apresentadas as abordagens para realizao de checkpoints em memria baseada em vizinhos, paridade, checksum, checksum com pesos e atravs de codificao.
O modelo proposto neste trabalho, tem por objetivo utilizar uma combinao de abordagens para realizao de checkpoints. O meio de persistncia principal em memria,
pelo fato deste se apresentar como um meio mais eficiente e rpido, se comparado com
a persistncia normal em disco. Essa rapidez especialmente importante por se tratar
de um mecanismo de checkpoint que tem como premissa realizar suas operaes de maneira rpida. Entretanto, realizar as operaes de checkpoint somente em memria pode
ser arriscado, posto que manter as informaes produzidas somente em memria pode se
tornar um problema quando o recurso em questo sofrer alguma falha ou for reiniciado.
Para mitigar esse problema, o modelo proposto engloba tambm recursos para realizao de checkpoints peridicos em disco, atravs da realizao de snapshots da execuo.
O prottipo implementado nessa dissertao no utiliza nenhuma tcnica especfica de
checkpoint em memria. Para o mecanismo descrito aqui, todas as manipulaes de objetos realizadas pela aplicao-alvo so encapsuladas dentro de um conceito de transao
que persistida de modo que, em caso de falhas ou interrupes, possam ser recuperadas
para reutilizao.
72
MODELO PROPOSTO
O termo checkpoint pode ser definido como a ao de armazenar o estado de uma

aplicao em execuo para sua recuperao posterior, evitando perda de informaes
processadas bem como garantindo a estabilidade de execuo. O estudo apresentado nessa
dissertao detalhou duas das principais abordagens para checkpoint: armazenamento
baseado em disco e armazenamento baseado em memria, apresentando as principais
implementaes existentes, dentro dessas abordagens.
As concluses derivadas desse estudo mostraram que ambas as abordagens possuem
vantagens e desvantagens, se mostrando como solues complementares. Com base nisso,
este captulo apresenta a idia de um modelo para realizao de checkpoints que fundamentado em uma abordagem que unifica os dois mecanismos apresentados: disklesscheckpoint, realizado atravs da utilizao do conceito de prevalncia de objetos, combinado com a persistncia peridica em disco, realizada em intervalos de tempo prdefinidos e de acordo com o recurso envolvido.
Esse captulo tambm detalha a implementao de um prottipo para validar o modelo
proposto. Alm do detalhamento do modelo e das caractersticas do prottipo, tambm
so apresentados alguns resultados preliminares, obtidos a partir da execuo do modelo
dentro de um cenrio proposto.
5.1
Origem da Proposta
A proposta apresentada e estudada nessa dissertao surgiu da idia da possibilidade

de utilizar MFPs como recursos teis para ambientes de computao voluntria. Uma
MFP pode ser definida como uma mquina que incorpora a funcionalidade de mltiplos
equipamentos em apenas um, oferecendo recursos e funcionalidades de impressora, scanner, foto-copiadora, fax e e-mail.
Para um correto entendimento da aplicao do modelo de checkpoint nesse tipo de
recurso, importante destacar os principais pontos em termos de hardware e software na
arquitetura interna de uma MFP.
5.1.1
Arquitetura Interna de uma MFP
A arquitetura interna de uma MFP pode ser comparada arquitetura de um desktop

tradicional, pois apresentam caractersticas semelhantes em termos de hardware e software, embora tenham objetivos distintos. Como apresentado abaixo, grande parte das
MFPs disponveis no mercado atualmente possuem configuraes suficientes para permitir a execuo de aplicaes voluntrias.
73
5.1.1.1
Hardware
Em termos de hardware, impressoras multifuncionais podem ser comparadas com

componentes perifricos convencionais, mas que so capazes de funcionar normalmente
sem a utilizao de computadores propriamente ditos. Nesses termos, correto afirmar que MFPs podem ser classificadas como tipos de computadores. De acordo com
(HEWLETT-PACKARD, 2009), as impressoras multifuncionais modernas contm memria, um ou mais processadores e, freqentemente, algum tipo de armazenamento fsico,
como disco fsico ou memria flash.
A tabela 5.1 apresenta alguns exemplos de especificaes de multifuncionais retiradas
de (HEWLETT-PACKARD, 2009):
Tabela 5.1: Configuraes de MFPs
Modelo
Vel. Processador Memria
Disco
HP CM8060
1.6GHz
1GB
80GB
HP CM3530
515MHz
512MB
40GB
HP CM4730
533MHz
448MB
40GB
HP CM2320
450MHz
160MB No Possui
HP CM6030
835MHz
512MB
80GB
Da mesma forma, a tabela 5.2 apresenta multifuncionais retiradas de (LEXMARK,
2009).
Modelo
Vel. Processador Memria
Disco
Lexmark X546dtn
500MHz
256MB No Possui
Lexmark X860de 3
800MHz
256MB
20GB
Lexmark X782e XL
800MHz
768MB
40GB
Lexmark X654de
600MHz
256MB
40GB
Lexmark X544n
500MHz
128MB No Possui
Pelas informaes apresentadas, possvel confirmar que a configurao desses equipamentos se assemelha bastante com caractersticas de computadores normais, permitindo que, em estando disponveis para o processamento voluntrio, produzam resultados
vlidos.
5.1.1.2
Software
Impressoras multifuncionais, assim como um computador normal, executam um conjunto de instrues a partir do seu firmware, que pode ser comparado a um sistema operacional. De fato, como o tamanho, complexidade e nmero de funcionalidades aumenta
consideravelmente, grande parte das multifuncionais disponveis no mercado fazem uso
de sistemas operacionais tradicionais para possibilitar o controle das diversas funcionalidades e recursos oferecidos pela multifuncional. Em (INC, 2009) so apresentados como
exemplos de sistemas operacionais, o Windows NT 4.0 Embedded, Windows XP Embedded, Windows CE e at mesmo Mac OS X.
Alm das funcionalidades disponveis no sistema operacional, as multifuncionais oferecem diversos recursos, como aplicaes, daemons ou servios. Esses recursos so cons-
74
trudos sobre o sistema operacional e possibilitam o controle do equipamento bem como

a interao com os usurios. Como exemplos desses recursos, podem ser listados:
Painel de controle, para permitir a interao com o usurio;
Web Server, para as funes de gerenciamento remoto;
Interpretadores bytecode ou mquinas virtuais, para aplicaes de terceiros que possam estar hospedadas na MFP;
Clientes e Servidores de rede, para envio e recebimento de documentos para diferentes destinos dentro da rede;
Funes para converso e processamento de imagens.
5.1.2
MFPs em Computao Voluntria
Apesar das MFPs serem equipamentos consistentes e com caractersticas semelhantes

a computadores normais, no so equipamentos utilizados como recursos para ambientes
de computao voluntria, especialmente por dois motivos:
Produzem pequenos (porm constantes) intervalos de disponibilidade.
Os workers disponveis no so adaptados para esse tipo de recurso.
Com essas caractersticas, mesmo que um worker pudesse ser instalado em um recurso
desse tipo, ele dificilmente conseguiria produzir algum resultado vlido pois o perodo
em que esse tipo de equipamento fica disponvel para o processamento voluntrio muito
curto. Isso significa que a MFP inicializaria a execuo de uma aplicao voluntria mas
no conseguiria atingir o intervalo de checkpoint para persistir os resultados produzidos,
pois possivelmente receberia algum job para processar.
Em (HEWLETT-PACKARD, 2009) e (LEXMARK, 2009), conhecidos produtores de
MFPs, possvel encontrar informaes que do conta que uma MFP permanece, em
mdia, 70% do tempo de maneira ociosa. Esse perodo ocioso poderia ser utilizado para
a produo de resultados para aplicaes voluntrias, caso os problemas descritos acima
fossem mitigados. Para verificar, em termos prticos, a disponibilidade de utilizao de
uma impressora multifuncional foi medida sendo que a imagem 5.1 mostra o grfico produzido. Esse grfico, em conjunto com a a tabela 5.3, representa a mdia de utilizao
de uma impressora MFP durante 8 horas de jornada de trabalho dentro de um laboratrio
de pesquisa com aproximadamente 30 usurios. Para a montagem do grfico, a atividade
de uma MFP foi medida, durante um perodo de um ms (descartando finais de semana).
Para cada jornada em que as medies eram realizadas, o status da multifuncional era
verificado em intervalos de 2 minutos. Com as informaes recebidas, foi calculada uma
mdia diria de utilizao da impressora. Essa mdia aritmtica simples teve desvio padro de = 1.23. O resultado dessa medio pode ser verificado no grfico 5.1, onde os
picos indicam os perodos onde a MFP estava em sleep-mode.
Os valores descritos acima foram obtidos atravs de uma aplicao desenvolvida especialmente para esse fim. Trata-se de um aplicativo simples que disparado e interrompido
automaticamente em horrios definidos. Durante a sua execuo, em intervalos de 2 minutos, requisies SNMP eram realizadas impressora e a resposta obtida armazenada
em arquivos que foram, posteriormente, utilizados para coletar e analisar os resultados.
75
Figura 5.1: Fluxo de utilizao diria de uma MFP

Informao
Valor
Nmero de Jobs
117
Tempo em Sleep-Mode 05:25
Tempo Processando
02:35
Essa validao comprova a utilidade de produzir um worker que esteja adaptado a

executar jobs, nesse tipo de recurso que apresenta curtos, porm constantes, perodos de
ociosidade. Para que isso se apresente como vivel, um dos primeiros passos produzir
um mecanismo de checkpoint que possa ser realizado de maneira freqente e rpida, sem
maiores custos ao processamento normal do recurso.
O modelo apresentado nesse captulo trata de uma proposta para um mecanismo de
checkpoint, focado em recursos com perodos curtos porm freqentes de disponibilidade, utilizando conceitos de diskless checkpoint em conjunto com persistncia em disco,
utilizando prevalncia de objetos. As principais caractersticas desse modelo so:
Checkpoint rpido: o modelo deve possibilitar a realizao de operaes de checkpoint de maneira rpida e transparente. Isso significa que a utilizao normal do
recurso no deve ser afetada pelo mecanismo de checkpoint proposto;
Diskless Checkpoint: para permitir a realizao do checkpoint de maneira mais
rpida, conceitos de diskless checkpoint so utilizados. Isso significa que as informaes intermedirias produzidas so mantidas em memria, evitando gargalos de
I/O;
Prevalncia de Objetos: o conceito de prevalncia de objetos, descrito na sequncia
desse captulo, utilizado para permitir que as informaes intermedirias produzidas sejam armazenadas em memria e, eventualmente, em disco.
76
Figura 5.2: Fluxo bsico de execuo do Modelo
5.2
Viso Geral do Modelo
O modelo apresentado trata de uma soluo que faz uso de abordagens de checkpoint
em memria atravs de prevalncia de objetos, aliada com checkpoints peridicos em
disco. Nesse modelo, ao iniciar o perodo de inatividade, o mecanismo de checkpoint
proposto busca em memria (e eventualmente em disco) por possveis informaes intermedirias j produzidas, a fim de retomar a execuo sem perda dos resultados. Nessa
proposta, tanto o armazenamento quanto a recuperao das informaes devem ser realizados de maneira rpida, no afetando a utilizao normal do recurso.
O diagrama de atividades apresentado na figura 5.2 apresenta o fluxo de execuo que
obedecido pelo modelo.
Ao entrar em um perodo de inatividade, o recurso passa a estar apto a iniciar a execuo de aplicaes dentro do modelo de computao voluntria. Isso significa que, ao
invs da MFP entrar em sleep-mode, ela passa a estar disponvel para o incio do processamento das aplicaes, dentro da plataforma voluntria. No momento em que o sinal
77
de sleep-mode reconhecido pelo device, o mecanismo de checkpoint proposto passa

a ser executado, para recuperar informaes intermedirias j produzidas e encapsular
a execuo do worker dentro de um contexto de prevalncia, mantendo as informaes
produzidas para utilizao futura.
O primeiro passo do algoritmo, implementado por esse modelo e apresentado no fluxo
acima, verificar a existncia de dados intermedirios j produzidos, em memria. O
mecanismo de checkpoint ser capaz de encontrar informaes produzidas em memria
caso a aplicao j tenha sido realizada dentro do contexto de prevalncia, no recurso em
questo. Caso no tenha sido encontrada nenhuma informao em memria, o mecanismo
de checkpoint procura por informaes persistidas em disco. Caso alguma informao
tenha sido encontrada, esta utilizada como ponto de incio da aplicao. Nesse cenrio,
os resultados intermedirios j produzidos so reaproveitados e a aplicao retoma sua
execuo no ponto onde foi previamente interrompida. Entretanto, caso no seja possvel
encontrar informaes em memria ou disco, a execuo da aplicao retomada desde
seu incio. Nesse caso, nenhum resultado intermedirio foi considerado, pois no foi
possvel encontrar informaes que pudessem ser reaproveitadas.
Tendo sido recuperado o contexto de execuo e o ponto de incio da nova execuo
tenha sido marcado, a execuo retomada. A aplicao-alvo do modelo encapsulada
dentro de um contexto de prevalncia de objetos de modo que todas as modificaes em
dados da aplicao sejam realizadas dentro de uma transao prevalente, para que tenham
seu contexto armazenado. Isso significa que todas as informaes produzidas sero armazenadas em um contexto prevalente e estaro disponveis para futura recuperao, em
caso de interrupes. Alm do armazenamento das informaes em memria, o mecanismo de checkpoint proposto realiza, de maneira peridica, eventuais serializaes dos
dados em disco fsico. Esse armazenamento em disco importante para evitar que as
informaes sejam mantidas apenas em memria, evitando possveis erros ou perdas em
caso de quedas de energia ou para eventuais operaes de restart do equipamento.
A execuo do job segue ativa at que o recurso receba um sinal, indicando o trmino do sleep-mode. Nessa situao, a execuo da aplicao-alvo imediatamente interrompida e os resultados at ento produzidos so armazenados em memria. Quando
o usurio proprietrio do recurso solicita a utilizao do meio, toda e qualquer atividade
voluntria interrompida e a capacidade de processamento do recurso devolvida em sua
totalidade para o proprietrio. Entretanto, as informaes intermedirias produzidas so
mantidas em memria e os eventuais checkpoints em disco que tenham sido realizados
permanecem disponveis para consultas futuras. Essas informaes mantidas em memria e em disco sero utilizadas como alimentao inicial para o mecanismo de checkpoint
no prximo ciclo de inatividade.
Atravs da utilizao de arquivos de configurao possvel determinar a realizao
dos checkpoints peridicos em disco. Essa configurao permite que snapshots da execuo sejam realizados em perodos de tempo pre-estabelecidos e armazenados em disco
fsico. Essa atividade realizada durante a execuo da aplicao-alvo, sem prejudicar
o desempenho e a produo dos resultados. A realizao do checkpoint peridico no
est associada a nenhuma premissa mnima e no possui nenhuma limitao em termos
de intervalos mnimos. Isso significa que possvel realizar checkpoints em disco com a
periodicidade necessria, de acordo com a aplicao a ser executada, dentro das caractersticas desejadas pelo administrador do sistema.
Todo o armazenamento das informaes intermedirias produzidas realizado atravs da utilizao do conceito de prevalncia de objetos, atravs da implementao em
78
Java, Prevayler. Os conceitos envolvidos com a prevalncia de objetos so apresentados

na seqencia desse captulo. Em relao aplicao-alvo, esta deve ser brevemente modificada para implementar uma interface especfica do modelo de checkpoint, estendendo
uma classe especfica do modelo. Essas modificaes so importantes para que o mecanismo de checkpoint proposto possa ser aplicado aplicao em que se deseja habilitar o
conceito de checkpoint.
5.3
Prevalncia de Objetos para Persistncia
A prevalncia de objetos pode ser definida como um modelo de persistncia em memria que pode ser utilizado para armazenamento de objetos de uma determinada aplicao (VILLELA, 2002; DEARLE et al., 2009). A principal diferena entre o modelo de
persistncia atravs de prevalncia de objetos, quando comparado com linguagens persistentes ou banco de dados orientados a objetos, est no fato de que a cpia primria dos
objetos reside permanentemente em memria. Em um sistema de banco de dados orientado a objetos, a cpia primria das informaes mantida em disco e as informao so
dinamicamente alocadas para memria, por um espao de tempo especfico.
Object Prevalence um conceito proposto em (WUESTEFELD, ????). A idia central
desse mecanismo manter tudo em memria RAM, como se estivesse trabalhando diretamente com uma linguagem de programao (VILLELA, 2002). Object Prevalence um
conceito simples que pode ser implementado em qualquer linguagem orientada a objetos,
onde seja possvel realizar serializao de objetos. Linguagens relativamente modernas,
como C# e Java, do suporte para que sejam realizadas serializaes de objetos e, portanto, se oferecem como plataformas vlidas para que o conceito de prevalncia de objetos
seja aplicado. O modelo proposto por Wuestefeld tambm apresenta implementaes em
outras linguagens de programao, como mostrado na tabela 5.4
Tabela 5.4: Implementaes do Modelo de Prevalncia
Implementao
Linguagem de Programao
Prevayler
Java
Bamboo
C#.NET
Py Per Syst
Python
Perlvayler
Perl
Common Lisp Prevalence
Common Lisp
Madeleine
Ruby
Em um sistema prevalente, toda e qualquer manipulao de objetos persistentes
realizada em memria. Isso significa que tanto alteraes quanto buscas de informaes
previamente armazenadas realizada em memria. Um sistema prevalente no faz uso de
nenhum banco de dados ou servidor de aplicao. As alteraes em objetos persistentes
so realizadas atravs de transaes especficas do modelo, garantindo que as informaes
sejam guardadas em memria para utilizaes futuras.
A persistncia dos objetos em memria, em sistemas prevalentes, feita atravs da
utilizao de dois conceitos amplamente utilizados em sistemas gerenciadores de banco
de dados orientados a objetos: log e snapshot. O log de transao implementado pelo
modelo de prevalncia e est associado com a utilizao de classes especficas para a
representao de transaes em um sistema prevalente. Isso significa que a aplicao
79
Figura 5.3: Atividades do Modelo de Prevalncia

prevalente, ao utilizar o conceito de transaes definido pelo modelo de prevalncia, est
habilitando a realizao de logs para cada modificao realizada sobre os objetos envolvidos na transao.
O snapshot um recurso que pode ser utilizado pela aplicao prevalente para realizar
a persistncia em disco das informaes persistidas em memria. Em outras palavras,
atravs da realizao de operaes de snapshot, o estado de todos os objetos persistidos
em memria so serializados e as informaes armazenadas em disco.
Os mecanismos de log e snapshot so complementares e utilizados em conjunto para
permitir a persistncia das informaes atravs da prevalncia de objetos. Como mencionado, para a operao realizada sobre as transaes do modelo de prevalncia, informaes de log so geradas de maneira automtica. Entretanto, a realizao de snapshots
somente realizada atravs da interveno direta da aplicao prevalente, no sendo realizada de maneira automtica.
O algoritmo bsico realizado pelo modelo de prevalncia pode ser representado atravs do diagrama de atividades apresentado na figura 5.3. A partir do momento em que
se realiza a restaurao do sistema prevalente em caso de falhas ou no reincio normal
da execuo, o modelo prevalente busca por snapshots existentes, disponveis em disco.
Caso encontre alguma informao, os dados persistidos so recuperados em memria. O
segundo passo a execuo de todos os logs criados aps o snapshot. Nesse momento, as
informaes do snapshot so atualizadas com eventuais modificaes que possam estar
armazenadas em log. Quando no se confirma a existncia de arquivos de snapshot em
disco, apenas a atividade de re-execuo das informaes de log realizada. Com isso, o
estado da aplicao prevalente recuperado, sendo equivalente ao estado anterior falha
ou ao desligamento do sistema.
5.4
Organizao do Modelo
A implementao do modelo que valida o conceito apresentado, foi realizada na linguagem Java fazendo uso da soluo Prevayler como modelo de prevalncia de objetos. A
soluo est organizada em trs pacotes bsicos, desconsiderando o componente de logs
que auxilia no processo de debug em caso de erros em tempo de execuo. A figura 5.5
apresenta os pacotes de soluo e o relacionamento existente entre eles:
O pacote PeriodicCheckpoint contm as classes que permitem a realizao das
operaes de checkpoint peridicos. Nesse mesmo pacote, est disponvel o arquivo de
configurao que possibilita a parametrizao do intervalo a ser obedecido para a realiza-
80
Figura 5.4: Organizao dos Pacotes do Modelo
Figura 5.5: Modificaes necessrias na aplicao-alvo

o do checkpoint. As informaes contidas no pacote TargetExtension permitem
que a aplicao-alvo seja estendida e adaptada ao modelo de prevalncia de objetos de
maneira transparente. O pacote TransactionData contm as classes que realizam
a configurao das transaes prevalentes que so utilizadas dentro do modelo. justamente atravs dessas classes prevalentes que a persistncia em memria e disco realizada. Os pacotes PeriodicCheckpoint e TransactionData esto diretamente
relacionados com o componente de prevalncia utilizado pelo modelo. Apesar da prottipo utilizar Prevayler como soluo de prevalncia, o modelo em si no est atrelado
a nenhuma soluo de prevalncia especfica. Isso significa que o componente de prevalncia pode ser substitudo por outra soluo, caso necessrio ou desejado. O modelo
implementado tambm faz uso, de maneira ampla, de um componente de logs criado para
possibilitar o armazenamento, de maneira transparente, de eventuais erros de execuo do
prottipo.
5.4.1
Aplicaes
O mecanismo de checkpoint implementado nesse modelo est preparado para trabalhar em aplicaes do tipo bag-of-tasks, que tenham sido previamente adaptadas ao modelo de checkpoint proposto. Aplicaes BoT podem ser entendidas como um caso de
aplicao paralela onde as tarefas so independentes. So, tipicamente, aplicaes simples que podem ser utilizadas em uma gama de cenrios, incluindo data mining, buscas
massivas, simulaes, processamento de imagens entre outros (CIRNE et al., 2003).
Para serem encapsuladas dentro do contexto de checkpoint, as aplicaes devem sofrer
trs pequenas modificaes, como descrito abaixo e representado atravs do modelo da
figura 5.5:
1. Implementar uma interface. A aplicao deve implementar ITargetApplication,
81
que a interface que define a existncia do mtodo para a inicializao de variveis

e do ponto de incio da aplicao-alvo;
2. Utilizar a varivel StartupValue. O mecanismo de checkpoint utiliza, via reflection, a varivel StartupValue como objeto de inicializao da aplicao;
3. Estender uma classe. A aplicao-alvo deve utilizar as classes disponibilizadas pelo
modelo para estender a classe ApplicationFacade;
4. Chamar o mtodo de prevalncia. O mtodo PrevalentExecution(Object
data) deve ser utilizado para encapsular a informao a ser persistida.
5.4.2
Implementando ITargetApplication
A aplicao-alvo a ser executada dentro do contexto de checkpoint proposto precisa implementar dois mtodos: start() e initializeProgram(). O mtodo
initializeProgram(), como o nome define, deve ser utilizado para realizar as inicializaes desejadas para a aplicao. A sua definio mandatria, entretanto, pode ter
o seu contedo vazio. Esse mtodo especialmente interessante quando a aplicao-alvo
realiza manipulaes de arquivos.
O mtodo start() deve conter o incio da aplicao. Para o prottipo definido, o
mtodo de start() deve ser entendido como o mtodo main(String args[]) de
uma aplicao tradicional Java. Trata-se do mtodo que ser invocado, via reflection, para
determinar o incio da aplicao-alvo.
Em tempo de execuo, o mecanismo de checkpoint proposto procura e invoca, via
reflection, o mtodo initializeProgram() para que possveis variveis da aplicao sejam inicializadas. Aps, o mtodo start() tambm chamado, via reflection,
para determinar o incio da aplicao-alvo, dentro de um contexto de prevalncia.
5.4.3
Utilizando a varivel StartupValue
Os resultados intermedirios produzidos e armazendos pelo mecanismo de checkpoint

so utilizados em futuras execues da aplicao. Para que seja possvel a correta inicializao do modelo e conseqente recuperao das informaes produzidas, a aplicaoalvo deve contemplar a existncia de uma varivel de StartupValue. Essa varivel
inicializada, em tempo de execuo, com o ltimo resultado vlido produzido.
No existe um tipo especfico esperado para a varivel. Isso significa que o tipo da
varivel StartupValue no precisa ser especfico, apenas o nome da varivel. Em
tempo de execuo o modelo vai recuperar a definio da varivel, identificar o seu tipo,
buscar a ltima informao produzida e inicializar o modelo de acordo.
5.4.4
Estendendo ApplicationFacade
A aplicao deve estender a classe ApplicationFacade para possibilitar a chamada do mtodo PrevalentExecution que define o encapsulamento dentro do conceito de prevalncia. A classe ApplicationFacade contm a implementao desse
mecanismo, que transparente para a aplicao-alvo. Em termos finais de utilizao,
ao projetar a aplicao-alvo, deve-se apenas ter o cuidado de realizar a chamada desse
mtodo, como descrito a seguir.
82
5.4.5
Invocando a Prevalncia
indicada a realizao da chamada desse mtodo sempre que algum resultado intermedirio tenha sido produzido, seja ele vlido ou no. Isso significa que, em uma
aplicao BoT, a informao a ser utilizada pela aplicao deve ser encapsulada dentro do
conceito de prevalncia, atravs da chamada do mtodo PrevalentExecution. Isso
garante que, em caso de falhas ou interrupes, o mecanismo de checkpoint ser capaz de
recuperar a execuo considerando os ltimos resultados intermedirios produzidos.
5.4.6
Exemplos de Modificaes
Para exemplificar as modificaes necessrias para permitir que uma aplicao possa
ser corretamente interpretada dentro do mecanismo proposto, foi projetada e implementada a aplicao abaixo. A aplicao em questo busca por nmeros de Mersenne primos,
que so nmeros inteiros positivos, primos, definidos por Mn = 2n 1 onde n tambm
um nmero inteiro positivo.
Listing 5.1: Exemplo de Aplicao-Alvo Modificada
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
p u b l i c c l a s s Mersenne e x t e n d s ApplicationFacade
i m p l e m e n t s ITargetApplication
{
p r i v a t e i n t StartupValue = 3 ;
p u b l i c v o i d initializeProgram ( ) { } ;
p u b l i c v o i d start ( ) {
i n t upb = 5 0 0 0 ;
f o r ( i n t p = StartupValue ; p <= upb ; p += 2 )
i f ( isPrime ( p ) && isMersennePrime ( p ) )
{
System . out . print ( " M" + p ) ;
t h i s . PrevalentExecution ( p ) ;
}
}
p u b l i c s t a t i c b o o l e a n isPrime ( i n t p ) {
i f ( p == 2 )
return true ;
e l s e i f ( p <= 1 | | p % 2 == 0 )
return false ;
else {
i n t to = ( i n t ) Math . sqrt ( p ) ;
f o r ( i n t i = 3 ; i <= to ; i += 2 )
i f ( p % i == 0 )
return false ;
return true ;
}
}
p u b l i c s t a t i c b o o l e a n isMersennePrime ( i n t p ) {
i f ( p == 2 )
return true ;
else {
BigInteger m_p = BigInteger . ONE . shiftLeft ( p ) . subtract ( BigInteger . ONE ) ;
BigInteger s = BigInteger . valueOf ( 4 ) ;
f o r ( i n t i = 3 ; i <= p ; i++)
s = s . multiply ( s ) . subtract ( BigInteger . valueOf ( 2 ) ) . mod ( m_p ) ;
r e t u r n s . equals ( BigInteger . ZERO ) ;
}
}
}
As linhas 1 e 2 mostram a interface sendo implementada, bem como a classe sendo

estendida. Como a aplicao em questo no precisa realizar nenhuma inicializao de
variveis ou propriedades especficas, o mtodo initializaProgram() est defi-
83
Figura 5.6: Diagrama de Classes do Mecanismo de Checkpoint

nido vazio na linha 5. A linha 4 mostra a definio da varivel esperada pelo modelo. Por
fim, a linha 7 define o mtodo principal da aplicao-alvo. Com as modificaes descritas acima, a aplicao est apta a ser executada dentro de um contexto de prevalncia de
objetos, para o modelo de checkpoint proposto.
5.5
Arquitetura do Mecanismo de Checkpoint
O mecanismo de checkpoint responsvel pelo armazenamento das informaes prevalentes realizado atravs da interao das classes representadas pelo diagrama da figura
5.6.
Esse conjunto de classes responsvel por encapsular a execuo das aplicaes dentro do modelo de prevalncia, permitindo que resultados intermedirios produzidos sejam
persistidos em memria e, eventualmente, serializados em disco. Cada um dos componentes do modelo mostrados no diagrama de classe da figura 5.6 detalhado em uma das
sees seguintes desse captulo.
84
Figura 5.7: Diagrama de Sequncia do Mecanismo de Checkpoint

Como dito anteriormente, as classes do modelo de checkpoint interagem entre si para
habilitar um mecanismo de checkpoint. O diagrama de seqencia mostrado na figura 5.7
detalha o fluxo bsico seguido pelo mecanismo de checkpoint.
A classe MainFacade responsvel por determinar o incio do fluxo bsico do modelo, atravs de uma chamada assncrona para a thread ApplicationJob. Esse componente responsvel por instanciar o TargetApplicationDecorator com os parmetros de execuo corretos para a aplicao-alvo e determinar o incio da execuo do
job. A classe TargetApplicationDecorator engloba as principais funcionalidades do modelo, chamadas por meio de operaes de reflection, dos mtodos de inicializao e incio da aplicao-alvo. Ao mesmo tempo, essa classe responsvel por instanciar
a criao de uma nova thread deamon para a realizao de checkpoints peridicos atravs
da classe PeriodicCheckpoint. Com a aplicao-alvo inicializada, esta responsvel pela chamada das execues prevalentes atravs da ApplicationFacade.
A organizao das threads existentes no mecanismo de checkpoint proposto pode ser
representada pela figura 5.8. Nela possvel identificar que a thread principal, atravs
da classe MainFacade dispara o incio de execuo da thread daemon da aplicaoalvo, atravs de um decorator que, por sua vez, tambm responsvel pela inicializao
do processo de execuo peridica de checkpoints. A partir do momento em que a thread principal finalizada, as demais threads so interrompidas, tendo seu ciclo de vida
finalizado.
5.5.1 ITargetApplication
A interface ITargetApplication define os mtodos que devem ser implementados pela aplicao-alvo, para que o conceito de prevalncia possa ser aplicvel. Ambos
os mtodos so chamados em tempo de execuo pelo mecanismo de checkpoint para
executarem as operaes e instrues especficas da aplicao. Todo programa em que
se deseja aplicar o modelo de checkpoint proposto deve, obrigatoriamente, implementar
85
Figura 5.8: Organizao das Threads do Modelo

essa interface e, por consequncia, prover uma implementao para os mtodos descritos
abaixo.
5.5.1.1 initializeProgram()
Nesse mtodo, apresentando na linha 5 da listagem da interface, devem estar contidas
as inicializaes especficas da aplicao. Variveis pblicas e privadas, abertura de arquivos e demais inicializaes do programa podem ser realizadas nesse mtodo. Em tempo
de execuo, o mecanismo de checkpoint realiza a chamada desse mtodo via reflection
permitindo que o programa seja corretamente inicializado.
5.5.1.2 start()
Demarca o ponto de incio da aplicao-alvo. O mecanismo de checkpoint utiliza esse
mtodo, definido na linha 7 da listagem, como ponto de entrada da aplicao, de maneira
equivalente ao mtodo main(String[] args) de uma aplicao normal. Em linhas
gerais, o ponto de incio da aplicao em que se deseja aplicar os conceitos de prevalncia
deve ser o mtodo start().
5.5.1.3
Listagem de Cdigo
Listing 5.2: Implementao da Interface ITargetApplication

1
2
3
4
5
6
7
8
9
p a c k a g e Checkpoint . TargetExtension ;
p u b l i c i n t e r f a c e ITargetApplication {
p u b l i c v o i d initializeProgram ( ) ;
p u b l i c v o i d start ( ) ;
}
5.5.2 MainFacade
A classe MainFacade tem como principal objetivo esconder a complexidade envolvida na inicializao da aplicao-alvo. Os mtodos expostos por essa classe e descritos
na seqncia, permitem que a aplicao-alvo possa ser iniciada e interrompida de maneira
86
transparente, encapsulando as particulariedades envolvidas nesse processo.

5.5.2.1 RunApplication(String applicationName)
Mtodo principal do modelo, que se apresenta como ponto de entrada para a execuo de aplicaes dentro do modelo de prevalncia proposto pelo checkpoint. O mtodo RunApplication(String applicationName) deve ser chamado pela plataforma de computao voluntria, recebendo como parmetro o caminho completo da
aplicao que deseja-se executar.
O nome da aplicao, recebido como parmetro, tambm utilizado para a criao
do repositrio especfico da aplicao. Esse repositrio serve para o armazenamento das
informaes de snapshots produzidas. A organizao de snapshots dentro de packages
especficos por aplicao permite que o modelo oferea suporte execuo de mltiplas
aplicaes de maneira transparente. Nessa abordagem, ao iniciar a execuo de uma
aplicao, o mecanismo de checkpoint procura por um package com o nome da aplicao
para ento recuperar as informaes de snapshots.
A linha 10 da listagem mostra que a aplicao-alvo executada dentro do modelo
como uma thread daemon. Esse tipo de thread, de acordo com (BRYANT; HARTNER,
2009) permite que um servio contemplado pela thread seja executado como tarefa de
background. Threads daemon tem o ciclo de vida delimitado pela execuo do programa
normal, o que significa que ela ser mantida enquanto o programa principal estiver em
execuo. Dentro do modelo do mecanismo de checkpoint proposto, executar a aplicaoalvo como uma thread daemon significa que o job ser executado enquanto no houverem
interrupes.
O principal objetivo desse mtodo encapsular a complexidade de inicializao e
chamada da thread que contm a execuo da aplicao-alvo. A linha 11 determina o
incio da execuo da thread da aplicao-alvo, atravs da classe ApplicationJob.
5.5.2.2 KillApplication()
Permite que a execuo da aplicao-alvo seja interrompida, devolvendo o processamento para outras atividades de maior prioridade. Dentro do modelo proposto, esse mtodo chamado quando o proprietrio do recurso computacional solicita a sua utilizao.
Nesse momento, toda e qualquer execuo ou processamento de atividades relacionadas
com o projeto voluntrio deve ser interrompida imediatamente.
Como a aplicao-alvo est sendo executada como uma thread daemon, o fluxo principal de execuo pode realizar a interrupo da execuo. A partir da interrupo da
thread da aplicao-alvo, as informaes intermedirias produzidas dentro do contexto
de prevalncia de objetos so mantidas em memria e eventuais snapshots armazenados
em disco.
A ao de interrupo da aplicao atravs da chamada ao mtodo em questo resulta
na finalizao imediata da thread daemon e tambm de eventuais threads criadas pela
aplicao-alvo. Esse processo inclui tambm o trmino da thread responsvel pela execuo peridica de snapshots, posto que esta tambm definida como uma thread daemon,
tpico que ser coberto na seqncia.
5.5.2.3
Listagem de Cdigo
87
Listing 5.3: Cdigo da classe MainFacade

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
p u b l i c c l a s s MainFacade {
p r i v a t e Thread jobThread ;
p u b l i c v o i d RunApplication ( String applicationName ) {
Runnable applicationJob = new ApplicationJob ( applicationName ) ;
jobThread = new Thread ( applicationJob ) ;
jobThread . setDaemon ( t r u e ) ;
jobThread . start ( ) ;
}
p u b l i c v o i d KillApplication ( ) {
jobThread . interrupt ( ) ;
}
}
5.5.3 ApplicationJob
A classe ApplicationJob, que estente a classe Thread, permite o incio da
aplicao-alvo. O construtor dessa classe recebe o nome da aplicao a ser executada
como parmetro e, atravs do mtodo run() encapsula a execuao da aplicao-alvo.
Como essa thread foi definida como daemon, seu ciclo de vida fica contido dentro da
MainFacade.
5.5.3.1 public void run()
A partir da chamada de execuo realizada pela MainFacade, a ApplicationJob
realiza a configurao do decorator para que a aplicao-alvo seja executada. Esse mtodo instancia um novo TargetApplicationDecorator passando o nome da aplicao recebida pelo construtor como parmetro e realiza a chamada do mtodo responsvel pela inicializao da aplicao-alvo. Atravs dos mtodos disponveis no decorator,
a produo de resultados intermedirios pode ser iniciada.
5.5.3.2
Listagem de Cdigo
Listing 5.4: Cdigo da classe ApplicationJob

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
p u b l i c c l a s s ApplicationJob e x t e n d s Thread{
p r i v a t e String _jobName ;
p u b l i c ApplicationJob ( String jobName ) {
t h i s . _jobName = jobName ;
}
@Override
p u b l i c v o i d run ( ) {
TargetApplicationDecorator decorator = new TargetApplicationDecorator ( t h i s . _jobName ) ;
decorator . RunApplication ( ) ;
}
}
88
5.5.4 TargetApplicationDecorator
A classe TargetApplicationDecorator o principal componente da arquitetura do mecanismo de checkpoint proposto. Atravs dela, esto disponveis mecanismos
para a recuperao das informaes intermedirias produzidas, inicializao da aplicaoalvo, configurao e incio do mecanismo de checkpoint peridico alm do incio da
aplicao-alvo, propriamente dita.
5.5.4.1 public void RunApplication()
Trata-se do principal mtodo do modelo de checkpoint proposto. Atravs desse mtodo, a aplicao-alvo a ser executada dentro do ambiente prevalente inicializada, parametrizada e tem sua execuo invocada. Esse o mtodo que contm as operaes
de inicializao com a ltima informao produzida, alm de contemplar as informaes
para chamada do mtodo initializeProgram e start.
A partir do nome da aplicao a ser executada, o mtodo RunApplication()
busca pela class da aplicao, via reflection e cria uma nova instncia da aplicaoalvo. A partir desse momento, o mtodo initializeProgram() procurado, dentro
da aplicao-alvo e, ao ser encontrado, sua execuo invocada. Nesse momento, a
aplicao-alvo est instanciada em memria e seus valores privados inicializados.
Com essas informaes, o mtodo RestoreInformation() (descrito na seqncia) chamado, fazendo com que o modelo de checkpoint verifique a existncia de possveis valores intermedirios produzidos e inicializando a aplicao, caso aplicvel. Alm
disso, como possvel verificar nas linhas 14-16 da listagem abaixo, o componente
responsvel pela execuo de checkpoints peridicos inicializado.
Por fim, o algoritmo implementando no mtodo RunApplication() chama, via
reflection, a execuo do mtodo start, dando incio execuo da aplicao-alvo. Nesse
momento, o modelo de checkpoint proposto criou uma nova instncia da aplicao-alvo,
inicializou a mesma com possveis valores j produzidos, configurou o incio da execuo peridica de checkpoints e inicializou a execuo da aplicao-alvo. A partir desse
momento, o fluxo de execuo passa a ser controlado pela aplicao-alvo, at que uma
interrupo ocorra ou que a aplicao-alvo finalize seu processamento.
Listing 5.5: Implementao do mtodo RunApplication
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
p u b l i c v o i d RunApplication ( ) {
try {
Class params [ ] = { } ;
Object paramsObj [ ] = { } ;
Class thisClass = Class . forName ( _applicationName . toString ( ) ) ;
_ApplicationClass = thisClass . newInstance ( ) ;
Method initializeMethod = thisClass . getDeclaredMethod ( " i n i t i a l i z e P r o g r a m " , params ) ;
initializeMethod . invoke ( _ApplicationClass , paramsObj ) ;
t h i s . RestoreInformation ( thisClass ) ;
Runnable periodicSnapshot = new PeriodicCheckpoint ( ) ;
Thread thread = new Thread ( periodicSnapshot ) ;
thread . start ( ) ;
Method startMethod = thisClass . getDeclaredMethod ( " s t a r t " , params ) ;
startMethod . invoke ( _ApplicationClass , paramsObj ) ;
}
c a t c h ( ClassNotFoundException cnf ) {
89
Figura 5.9: Diagrama de Seqncia do mtodo RestoreInformation

22
CheckPrevalentLog . getInstance ( ) . logError ( " T a r g e t A p p l i c a t i o n D e c o r a t o r " , "R u n A p p l i c a t i o n " , " C a u g h t an C l a s s N o t F o u n d E x c e p t i o n when t r y i n g t o r u n t h e t a r g e t a p p l i c a t i o n . " , cnf ) ;
23
24
25
}
c a t c h ( InstantiationException ie ) {
CheckPrevalentLog . getInstance ( ) . logError ( " T a r g e t A p p l i c a t i o n D e c o r a t o r " , "R u n A p p l i c a t i o n " , " C a u g h t an I n s t a n t i a t i o n E x c e p t i o n when t r y i n g t o r u n t h e t a r g e t a p p l i c a t i o n . " , ie ) ;
}
c a t c h ( IllegalAccessException iae ) {
CheckPrevalentLog . getInstance ( ) . logError ( " T a r g e t A p p l i c a t i o n D e c o r a t o r " , "R u n A p p l i c a t i o n " , " C a u g h t an I l l e g a l A c c e s s E x c e p t i o n when t r y i n g t o r u n t h e t a r g e t a p p l i c a t i o n . " , iae ) ;
}
c a t c h ( NoSuchMethodException nsm ) {
CheckPrevalentLog . getInstance ( ) . logError ( " T a r g e t A p p l i c a t i o n D e c o r a t o r " , "R u n A p p l i c a t i o n " , " C a u g h t an N o S u c h M e t h o d E x c e p t i o n when t r y i n g t o r u n t h e t a r g e t a p p l i c a t i o n . " , nsm ) ;
}
c a t c h ( InvocationTargetException ite ) {
CheckPrevalentLog . getInstance ( ) . logError ( " T a r g e t A p p l i c a t i o n D e c o r a t o r " , "R u n A p p l i c a t i o n " , " C a u g h t an I n v o c a t i o n T a r g e t E x c e p t i o n when t r y i n g t o r u n t h e t a r g e t a p p l i c a t i o n . " , ite ) ;
}
26
27
28
29
30
31
32
33
34
35
36
5.5.4.2 private void RestoreInformation (Class appClass)

O processo de recuperao das informaes intermedirias j produzidas fundamental para o modelo de checkpoint proposto funcionar como esperado. Esse fluxo
implementado no decorator atravs do mtodo RestoreInformation(). Esse mtodo recebe por parmetro a classe referente aplicao que se deseja executar e busca os
valores produzidos, incializando a aplicao de acordo.
O diagrama de seqncia apresentado na figura 5.9 detalha o fluxo observado por
esse mtodo. A classe TargetApplicationDecorator inicia o processo de recuperao das informaes intermedirias produzidas chamando, pelo mtodo run(),
a execuo do RestoreInformation(). Nesse momento, a instncia da classe
CheckpointData utilizada para buscar o ltimo resultado vlido produzido, atravs do mtodo lastData(). O valor retornado por essa execuo ser utilizado para
inicializar a aplicao-alvo que ser executada.
Com o ltimo valor produzido por execues anteriores identificado, o mecanismo
90
de checkpoint proposto est apto a inicializar a aplicao. Nesse momento, o mecanismo de checkpoint procura, na classe recebida por parmetro, pela existncia da varivel StartupValue, que definida como pr-requisito para inicializao da aplicao.
Tendo sido identificado o ltimo valor produzido e a varivel StartupValue, o prximo passo do algoritmo inicializar a varivel com o valor, de acordo com o tipo especfico que utilizado pela aplicao, atravs do mtodo initializeStartupValue().
5.5.4.3 private void initializeStartupValue(Field field)
A implementao desse mtodo, apresentado na listagem abaixo, oferece um mecanismo para que a varivel StartupValue seja inicializada com o ltimo valor produzido, em tempo de execuo por meio de reflection. O pr-requisito para que a inicializao da aplicao seja correta, a existncia de uma varivel com o nome StartupValue
na aplicao-alvo. Entretanto, no existem restries em relao ao tipo da mesma, o que
permite variaes de acordo com o interesse da aplicao.
O mtodo initializeStartupValue() realiza uma verificao, em tempo de
execuo, para identificar o tipo associado varivel em questo. A partir dessa informao, casts especficos so realizados para permitir que a aplicao tenha o valor inicial
ajustado conforme esperado. Para o caso onde a varivel StartupValue est associada utilizao de arquivos, o mtodo PositionateFilePointer() utilizado
para permitir que o ponteiro seja corretamente posicionado no arquivo.
Listing 5.6: Implementao do mtodo initializeStartupValue

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
p r i v a t e v o i d initializeStartupValue ( Field field )

{
try {
i f ( field . getType ( ) == i n t . c l a s s ) {
i f ( t h i s . _lastData ! = n u l l )
field . set ( _ApplicationClass , ( ( Integer ) t h i s . _lastData ) . intValue ( ) ) ;
}
i f ( field . getType ( ) == l o n g . c l a s s ) {
field . set ( _ApplicationClass , ( ( Long ) t h i s . _lastData ) . longValue ( ) ) ;
}
i f ( field . getType ( ) == d o u b l e . c l a s s ) {
field . set ( _ApplicationClass , ( ( Double ) t h i s . _lastData ) . doubleValue ( ) ) ;
}
i f ( field . getType ( ) == java . lang . String . c l a s s ) {
field . set ( _ApplicationClass , ( ( String ) t h i s . _lastData ) . toString ( ) ) ;
}
i f ( field . getType ( ) == BufferedReader . c l a s s ) {
_bufFile = ( BufferedReader ) field . get ( _ApplicationClass ) ;
i f ( t h i s . _lastData ! = n u l l ) {
PositionateFilePointer ( ) ;
field . set ( _ApplicationClass , _bufFile ) ;
}
}
} c a t c h ( IllegalAccessException iae ) {
CheckPrevalentLog . getInstance ( ) . logError ( " T a r g e t A p p l i c a t i o n D e c o r a t o r " , "i n i t i a l i z e S t a r t u p V a l u e " , " C a u g h t an I l l e g a l A c c e s s E x c e p t i o n when i n i t i a l i z i n g a p p l i c a t i o n v a l u e s . " , iae ) ;
}
}
91
5.5.4.4 private void PositionateFilePointer()

O mtodo apresentado na listagem abaixo utilizado durante o processo de inicializao do campo StartupValue para os casos onde o mesmo esteja associado utilizao
de arquivos. Nesse caso, esse mtodo descarta os chunks de arquivos que j foram lidos,
posicionando a leitura para a prxima informao a ser processada pela aplicao-alvo.
Listing 5.7: Implementao do mtodo PositionateFilePointer
1
2
3
4
5
6
7
8
9
p r i v a t e v o i d PositionateFilePointer ( ) {
try {
String junk ;
_filePtr = ( ( Long ) t h i s . _lastData ) . longValue ( ) ;
f o r ( i n t i = 0 ; i < _filePtr ; i++) { junk = _bufFile . readLine ( ) ; }
} c a t c h ( IOException io ) {
CheckPrevalentLog . getInstance ( ) . logError ( " T a r g e t A p p l i c a t i o n D e c o r a t o r " , "P o s i t i o n a t e F i l e P o i n t e r " , " C a u g h t an I O E x c e p t i o n when e l i m i n a t i n g j u n k i n f o r m a t i o n " , io ) ;
}
}
5.5.5 PeriodicCheckpoint
O modelo do mecanismo de checkpoint proposto define que operaes de checkpoint
em disco devam ser executadas de maneira peridica. Esse armazenamento em disco
das informaes peridicas produzidas realizado atravs da execuo de snapshots cujo
resultado produzido armazenado em disco. A classe PeriodicCheckpoint responsvel pelo controle e execuo da realizao desses snapshots em disco, atravs do
modelo de prevalncia adotado.
A classe projetada como uma thread daemon criada a partir do decorator, quando a
configurao e reincio da aplicao-alvo realizada. O checkpoint realizado de maneira
peridica, em intervalos de tempo pr-estabelecidos e configurados em um arquivo de
parametrizao.
No existem limitaes tcnicas em relao ao intervalo a ser utilizado. Isso significa
que o modelo pode ser configurado para realizar operaes de checkpoint em disco em intervalos muito curtos, como segundos, ou longos, como horas. Entretanto, a execuo de
maneira muito frequente pode acarretar perdas de processamento, posto que para a realizao da persistncia em disco das informaes, necessria a realizao da serializao
das informaes mantidas em memria.
A configurao do intervalo de tempo a ser respeitado pelo modelo deve ser realizada
no arquivo checkprev.properties. A parametrizao deve ser feita utilizando a
propriedade periodic_checkpoint e o valor a ser utilizado deve ser expressado em
ms.
5.5.5.1 public void run()
A execuo de checkpoints realizados em intervalos de tempo definidos como descrito
acima realizado no mtodo principal da thread, atravs de uma iterao infinita, como
mostrado na linha 26. Por ser classificada como daemon, a thread ter seu ciclo de vida
finalizado assim que a execuo da aplicao-alvo for interrompida. Enquanto a produo
de resultados no interrompida, a thread que realiza os checkpoints peridicos utiliza
a classe ApplicationFacade para realizar chamadas de execuo de snapshots do
modelo de prevalncia.
92
5.5.5.2
Listagem de Cdigo
Listing 5.8: Cdigo da classe PeriodicCheckpoint

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
p a c k a g e Checkpoint . PeriodicCheckpoint ;
import
import
import
import
import
p u b l i c c l a s s PeriodicCheckpoint e x t e n d s Thread{
p u b l i c PeriodicCheckpoint ( ) {
setDaemon ( t r u e ) ;
}
@Override
p u b l i c v o i d run ( ) {
try {
ApplicationFacade extension = new ApplicationFacade ( ) ;
Properties properties = new Properties ( ) ;
String propPath = " / C h e c k p o i n t / P e r i o d i c C h e c k p o i n t / c h e c k p r e v . p r o p e r t i e s "
properties . load ( t h i s . getClass ( ) . getResourceAsStream ( propPath ) ) ;
i n t ckpt =Integer . parseInt ( properties . getProperty ( " p e r i o d i c _ c h e c k p o i n t " ) ) ;
while ( t r u e ) {
Thread . sleep ( ckpt ) ;
extension . TakeSnapshot ( ) ;
}
}
c a t c h ( InterruptedException ie ) {
CheckPrevalentLog . getInstance ( ) . logError ( " P e r i o d i c C h e c k p o i n t " , " r u n " , "C a u g h t an I n t e r r u p t e d E x c e p t i o n on t h e P e r i o d i c C h e c k p o i n t e x e c u t i o n . " , ie ) ;
}
c a t c h ( FileNotFoundException fnf ) {
CheckPrevalentLog . getInstance ( ) . logError ( " P e r i o d i c C h e c k p o i n t " , " r u n " , "C a u g h t an F i l e N o t F o u n d E x c e p t i o n on t h e P e r i o d i c C h e c k p o i n t e x e c u t i o n . " , fnf ) ;
}
c a t c h ( IOException io ) {
CheckPrevalentLog . getInstance ( ) . logError ( " P e r i o d i c C h e c k p o i n t " , " r u n " , "C a u g h t an I O E x c e p t i o n on t h e P e r i o d i c C h e c k p o i n t e x e c u t i o n . " , io ) ;
}
33
34
35
36
37
38
39
40
41
42
Checkpoint . log . CheckPrevalentLog ;

Checkpoint . TargetExtension . ApplicationFacade ;
java . io . FileNotFoundException ;
java . io . IOException ;
java . util . Properties ;
}
}
5.5.6 PrevalenceHelper
A classe PrevalenceHelper permite configurar as informaes referentes prevalncia, para o modelo de checkpoint proposto. Alm dessa configurao bsica das
informaes de prevalncia, esse helper utilizado como objeto-base, de onde as classes
do tipo TargetApplicationDecorator e ApplicationFacade herdam. Em
linhas gerais, a PrevalenceHelper responsvel por criar o repositrio onde as classes especializadas iro depositar as informaes intermedirias produzidas.
5.5.6.1 public PrevalenceHelper(String applicationName)
O construtor da classe recebe o nome da aplicao-alvo que ser executada no ambiente voluntrio. Essa informao recebida por parmetro importante para permitir a
93
configurao, em disco, dos packages onde as informaes de snaphot sero armazenadas.

Quando o construtor do PrevalenceHelper chamado, a configurao do ambiente de persistncia de objetos atravs de prevalncia realizada atravs do mtodo
setPrevayler().
5.5.6.2 public void setPrevayler()
No momento em que a instncia da classe PrevalenceHelper criada, o modelo
de checkpoint proposto cria, atravs da PrevaylerFactory do modelo de prevalncia
utilizado, a base de persistncia que ser utilizada durante a execuo da aplicao.
O conjunto de objetos criados atravs desse mtodo possibilita que todos os objetos
manipulados pelas transaes prevalentes tenham seus resultados intermedirios armazenados. Como resultado final, o mtodo setPrevayler() disponibiliza para o modelo
de checkpoint proposto, o repositrio de informaes produzidas, que mantido no atributo esttico Prevayler.
5.5.6.3
Listagem de Cdigo
Listing 5.9: Cdigo da classe PrevalenceHelper

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
import
import
import
import
import
import
Checkpoint . TransactionData . CheckpointData ;

Checkpoint . log . CheckPrevalentLog ;
java . io . BufferedReader ;
java . io . IOException ;
org . prevayler . Prevayler ;
org . prevayler . PrevaylerFactory ;
p u b l i c c l a s s PrevalenceHelper {
p r i v a t e s t a t i c Prevayler prevayler ;
p r o t e c t e d s t a t i c String _applicationName ;
p r o t e c t e d s t a t i c l o n g _filePtr = 0 ;
p r o t e c t e d s t a t i c BufferedReader _bufFile = n u l l ;
@Deprecated
p u b l i c PrevalenceHelper ( ) { } ;
p u b l i c PrevalenceHelper ( String applicationName ) {
_applicationName = applicationName ;
setPrevayler ( ) ;
}
p u b l i c Prevayler getPrevayler ( ) {
r e t u r n prevayler ;
}
p u b l i c v o i d setPrevayler ( ) {
try {
i f ( prevayler == n u l l )
prevayler = PrevaylerFactory . createPrevayler ( new CheckpointData ( ) , "C h e c k p o i n t \ \ " + _applicationName ) ;
}
CheckPrevalentLog . getInstance ( ) . logError ( " P r e v a l e n c e H e l p e r " , " s e t P r e v a y l e r " , " C a u g h t an I O E x c e p t i o n when s e t t i n g t h e P r e v a y l e r . " , io ) ;
}
c a t c h ( ClassNotFoundException cnf ) {
94
Figura 5.10: Diagrama de Seqncia para o mtodo PrevalentExecution

CheckPrevalentLog . getInstance ( ) . logError ( " P r e v a l e n c e H e l p e r " , " s e t P r e v a y l e r " , " C a u g h t an C l a s s N o t F o u n d E x c e p t i o n when s e t t i n g t h e P r e v a y l e r . " , cnf);
41
42
43
44
}
}
}
5.5.7 ApplicationFacade
A aplicao-alvo a ser executada dentro do modelo de prevalncia proposto pelo mecanismo de checkpoint deve implementar uma interface e estender essa classe, como visto
anteriormente. A classe ApplicationFacade estende a classe PrevalenceHelper,
disponibilizando mtodos com funcionalidades de interesse da aplicao-alvo, para encapsulamento do processamento dentro de uma transao prevalente e tambm, caso seja
interesse da aplicao, realizar a execuo de snapshots.
5.5.7.1 public void PrevalentExecution(Object data)
O mtodo PrevalentExecution() tem como responsabilidade encapsular a execuo da transao do modelo prevalente. Atravs desse mtodo, possvel armazenar
as informaes intermedirias produzidas. O diagrama de seqncia apresentado na figura 5.9 mostra o fluxo observado quando a aplicao-alvo invoca a execuo desse mtodo. Nele possvel identificar a iterao entre os diversos objetos do modelo de checkpoint, at chegar na classe CheckpointTransaction, que encapsula a persistncia
da informao produzida.
Durante a execuo da aplicao-alvo, devem ser realizadas chamadas a esse mtodo para que o resultado produzido at o momento seja persistido. A partir do momento em que a chamada a esse mtodo realizada, a informao a ser armazenada
encapsulada dentro do conceito de transao atravs da utilizao de instncias da classe
CheckpointTransaction.
A aplicao-alvo executada dentro do modelo de prevalncia proposto deve, obrigatoriamente, realizar chamadas eventuais ao mtodo PrevalentExecution() para ter
suas informaes persistidas. Para os casos onde no sejam realizadas chamadas a esse
mtodo, a aplicao tem sua execuo realizada fora do contexto de prevalncia. Isso
significa que os resultados intermedirios produzidos no sero armazenados e, em caso
de interrupes ou falhas, a execuo ser retomada desde o incio.
Para os casos onde a aplicao-alvo trabalha produzindo resultados baseados em en-
95
tradas atravs de arquivos em disco, o mtodo PrevalentExecution mantm atualizado um ponteiro para a posio atual do arquivo. Esse ponteiro utilizado quando
for necessrio o reincio de uma aplicao aps uma interrupo, para que seja possvel
identificar o local, a partir do qual, o reincio da atividade deve ser realizada.
5.5.7.2 public void TakeSnapshot()
Atravs desse mtodo, a aplicao-alvo tem condies de chamar, de maneira direta,
a realizao de snapshots. Ao invocar o mtodo TakeSnapshot(), todas as informaes correntes da aplicao so serializadas em disco, permitindo recuperao e utilizao
futura.
5.5.7.3
Listagem de Cdigo
Listing 5.10: Cdigo da classe ApplicationFacade

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
i m p o r t Checkpoint . TransactionData . CheckpointTransaction ;
i m p o r t Checkpoint . log . CheckPrevalentLog ;
i m p o r t java . io . IOException ;
p u b l i c c l a s s ApplicationFacade e x t e n d s PrevalenceHelper{
p u b l i c v o i d PrevalentExecution ( Object data ) {
i f ( _bufFile ! = n u l l ) {
_filePtr += 1 ;
data = ( Object ) _filePtr ;
}
t h i s . getPrevayler ( ) . execute ( new CheckpointTransaction ( data ) ) ;
}
p u b l i c v o i d TakeSnapshot ( ) {
try {
t h i s . getPrevayler ( ) . takeSnapshot ( ) ;
}
CheckPrevalentLog . getInstance ( ) . logError ( " A p p l i c a t i o n E x t e n s i o n " , "T a k e S n a p s h o t " , " F a i l e d t o t a k e s n a p s h o t " , io ) ;
}
}
}
5.5.8 CheckpointTransaction
A classe CheckpointTransaction tem como principal funcionalidade utilizar a
classe CheckpointData, persistindo a informao no modelo de prevalncia de objetos. Essa classe implementa a interface Transaction definida pela soluo de prevalncia utilizada e, a partir disso, implementa o mtodo executeOn().
5.5.8.1 public void executeOn(Object prevalentSystem,
Date currentDate)
Quando a ao de persistncia invocada, a soluo de prevalncia utilizada chama,
de maneira indireta, a execuo desse mtodo. O executeOn() tem a responsabilidade
de encapsular e persistir a informao recebida por parmetro, como possvel ver na
linha 17. Tendo a informao intermediria a ser armazenada, o mtodo utiliza o objeto de prevalncia criado para ento, atravs da classe CheckpointData, realizar a
96
persistncia da informao.
Listing 5.11: Cdigo da classe CheckpointTransaction
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
p a c k a g e Checkpoint . TransactionData ;
i m p o r t java . util . Date ;
i m p o r t org . prevayler . Transaction ;
p u b l i c c l a s s CheckpointTransaction i m p l e m e n t s Transaction {
p r i v a t e Object _newData ;
p r i v a t e CheckpointTransaction ( ) {}
p u b l i c CheckpointTransaction ( Object newData ) {
_newData = newData ;
}
p u b l i c v o i d executeOn ( Object prevalentSystem , Date currentDate ) {
( ( CheckpointData ) prevalentSystem ) . persistData ( _newData ) ;
}
}
5.5.9 CheckpointData
A classe CheckpointData responsvel por manter o repositrio virtual onde as
informaes intermedirias produzidas pelo sistema prevalente so armazenadas. essa
classe que ser utilizada pela aplicao prevalente, atravs do modelo proposto, para o
armazenamento das informaes produzidas.
Na linha 7 est definido um ArrayList que a estrutura de dados onde a informao ser armazenada. Quando o mtodo persistData chamado, a informao a ser
armazenada recebida por parmetro e ento adicionada a essa estrutura de dados. Com
essa estrutura mantida, durante a execuo do sistema prevalente, possvel identificar as
informaes j armazenadas, bem como adicionar novas informaes.
A classe CheckpointData atualizada pela classe CheckpointTransaction.
Nessa operao, as novas informaes intermedirias produzidas atravs das transaes
prevalentes so adicionadas estrutura de dados mantida em memria. Da mesma forma,
esse objeto pode ser referenciado pela TargetApplicationDecorator para obteno das informaes j produzidas, teis quando a aplicao est sendo reiniciada aps
uma interrupo.
5.5.9.1 public void persistData(Object newData)
Uma das principais utilidades dessa classe a manuteno, em memria, das informaes intermedirias produzidas, atravs da utilizao de um ArrayList. A manuteno
dessas informaes realizada atravs do mtodo persistData.
Ao ser chamado, o mtodo espera receber como parmetro um objeto. Essa informao, recebida por parmetro, deve ser entendida como o resultado intermedirio produzido
e deve, portanto, ser adicionado estrutura de dados.
5.5.9.2 public Object lastData()
Quando o reincio de uma aplicao que foi previamente interrompida feito, o
modelo de checkpoint proposto precisa buscar por possveis informaes j produzidas.
Como definido na proposta, o primeiro lugar em que esses resultados intermedirios so
buscados na memria.
97
A busca por resultados intermedirios em memria realizada atravs do mtodo

lastData. Esse mtodo utiliza a estrutura de dados do arrayList para verificar a
ltima informao adicionada e retornar o contedo. Dessa forma, atravs desse mtodo,
a aplicao-alvo pode ser reiniciada com o ltimo resultado vlido produzido.
5.5.9.3 public ArrayList fullDump()
Quando chamado pelo modelo, o mtodo fullDump() retorna a estrutura de dados completa, com todos os valores intermedirios produzidos. Esse mtodo pode ser
utilizado quando deseja-se verificar todos os valores produzidos at o momento.
5.5.9.4
Listagem de Cdigo
Listing 5.12: Cdigo da classe CheckpointData

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
p a c k a g e Checkpoint . TransactionData ;
i m p o r t java . util . ;
p u b l i c c l a s s CheckpointData i m p l e m e n t s java . io . Serializable {
p r i v a t e ArrayList persistedData = new ArrayList ( ) ;
p u b l i c v o i d persistData ( Object newData ) {
i f ( newData ! = n u l l )
persistedData . add ( newData ) ;
}
p u b l i c Object lastData ( ) {
Object tmp = n u l l ;
i f ( persistedData . size ( ) > 0 )
tmp = persistedData . get ( persistedData . size ( ) 1) ;
r e t u r n tmp ;
}
p u b l i c ArrayList fullDump ( ) {
r e t u r n persistedData ;
}
}
5.6 Checkpoint para XtremWeb

O modelo de checkpoint descrito foi inicialmente projetado para ser adicionado plataforma XtremWeb, que um software de cdigo aberto, desenvolvido pela universidade
de Paris Sd, para construir desktop grids atravs da utilizao de recursos disponveis
dos computadores pessoais. Dentre as principais funcionalidades, esto includos suporte
a mltiplos usurios, mltiplas aplicaes e desenvolvimento de aplicaes entre plataformas, de maneira independente (INRIA, 2009).
A idia para a construo do XtremWeb surgiu de uma requisio feita pelos fsicos
do observatrio Pierre Auger, para que fosse possvel atingir e contemplar um processamento cujos requisitos eram muito grandes para serem resolvidos por mquinas comuns
(FEDAK et al., 2001). O problema era, basicamente, a execuo anual de uma determinada simulao que continha aproximadamente 6 105 entradas distintas. Para esse
processamento ser vivel, seriam necessrias 6 106 horas por ano de um computador
com 300MHz. Foi dentro desse contexto, que os pesquisadores da universidade de Paris
Sd iniciaram o desenvolvimento da plataforma.
98
Ainda de acordo com (INRIA, 2009) atravs da utilizao do XtremWeb, possvel

transformar um conjunto de recursos volteis, distribudos atravs de uma LAN ou mesmo
da internet, em um ambiente integrado para a execuo de aplicaes paralelas.
Na prtica, a plataforma oferecida pelo XtremWeb pode ser utilizada para o desenvolvimento de aplicaes nos campos das fsicas de altas energias, aplicaes biomoleculares, aplicaes matemticas e diversos outros domnios cientficos ou industriais.
Como definido em (INRIA, 2009), XtremWeb uma plataforma altamente programvel e customizvel, o que permite a sua aplicao tanto em solues baseadas em bagof-tasks ou mestre-escravo. Alm disso, essa flexibilidade permite que a plataforma seja
configurada para utilizar benefcios especficos da arquitetura onde est sendo executada
(clusters, multi-lan e outros), de maneira escalvel, gerencivel e muito segura.
Em (TOTH, 2004), o autor cita que o XtremWeb pode ser comparado ao BOINC, visto
anteriormente. Nessa comparao, o autor cita que XtremWeb oferece ferramentas para
auxiliar na criao de projetos para computao voluntria, assim como o BOINC. Como
aspecto que diferencia as duas solues, (TOTH, 2004) cita que a plataforma criada pela
universidade de Paris Sd somente permite que cada cliente receba uma tarefa de cada vez.
Nessa abordagem, aps processar essa tarefa, o cliente sinaliza o trmino da execuo e
envia os resultados, estando apto a solicitar uma nova tarefa.
Em (INRIA, 2009), essa comparao aprofundada e os autores citam que o XtremWeb
pode ser, em termos de comparao, colocado como uma soluo intermediria entre o
BOINC e o Condor. Comparado com o BOINC, o XtremWeb assume que cada usurio ou
nodo participante tem a possibilidade, se autorizado, de submeter jobs. Com o BOINC,
essa abordagem no permitida, onde somente os projetos podem submeter tarefas para
a aplicao. Se comparado com o Condor, a plataforma XtremWeb assume que os recursos computacionais podem ser difundidos atravs da internet. A maior diferena entre as
duas solues o fato de que o XtremWeb baseado em um modelo onde os workers buscam tarefas do servidor, enquanto que o Condor escolhe a melhor mquina para executar
determinada tarefa.
O objetivo principal da soluo desenvolvida pela universidade de Paris , baseado
em (FEDAK et al., 2001), criar uma plataforma onde fosse possvel tirar o maior proveito
possvel do conceito de computao global. Isso significa, disponibilizar mecanismos
para que mquinas, distribudas atravs do mundo pela internet, pudessem colaborar, de
maneira transparente, segura e simples, para a soluo de problemas e, alm disso, fossem
capazes de submeter novos problemas. Dentre as principais preocupaes, esto:
aumentar ou reduzir a quantidade de componentes (servidores, largura da banda de
rede, escravos) do ambiente, de acordo com a aplicao;
alta performance e execuo segura (para todos os participantes);
algoritmos de escalonamento devem ser responsveis pelo gerenciamento da carga
de trabalho;
impacto do tipo da aplicao a ser executada.
5.6.1
Segurana e Execuo de Cdigo Nativo
O XtremWeb busca cumprir as atividades que lhe so propostas em um tempo aceitvel. Em contraponto, necessrio tambm garantir aos participantes da grade segurana e
confiabilidade na execuo das tarefas. Para enderear ambos os requisitos, o XtremWeb
99
Figura 5.11: Protocolo de Comunicao entre workers

escrito em Java, linguagem que oferece a proteo e a portabilidade da mquina virtual.
Para cumprir com o objetivo de desenvolver as atividades com boa performance, todo o
cdigo final e as requisies de comunicaes diretas com os sistemas operacionais so
feitas de maneira nativa. No detalhamento dos workers, essa questo apresentada com
maiores detalhes.
5.6.2
Comunicao entre Workers e Servers
Desde o planejamento inicial do XtremWeb, a sua execuo foi prevista para ser realizada em ambientes globais, atravs da internet, por exemplo. Para facilitar o deployment
e configurao, toda e qualquer comunicao necessria parte dos workers. Essa abordagem se torna interessante, quando se pensa que em ambientes de computao globais, se
as requisies partissem de um servidor (fora da rede local de um dos participantes, por
exemplo), poderiam ser bloqueadas por firewalls.
De acordo com (FEDAK et al., 2001), o protocolo de comunicao a ser utilizado
entre os workers e os servidores totalmente independente da camada de comunicao.
Essa camada, responsvel por determinar como ser estabelecida a comunicao entre os
participantes, pode variar desde um modelo generalista como sockets via TCP-UDP/IP
at um mecanismo de maior nvel de abstrao como CORBA ou Java RMI. Essa flexibilidade e desacoplamento permitem, tambm, que sejam utilizados protocolos especficos,
adaptados realidade do problema a ser endereado, como SSL ou RSVP. De acordo com
(FEDAK et al., 2001), a primeira motivao para essa abordagem a segurana: com a
comunicao on-sided a segurana dos workers garantida atravs da autenticao, protegendo os dados que sero transmitidos. Outra motivao, ainda de acordo com (FEDAK
et al., 2001) a facilidade para desenvolvimento: as polticas de segurana do dispatcher
so configurveis, enquanto que as polticas do worker no so.
A figura 5.11 mostra como funciona essa camada de comunicao entre os workers
e os servidores. O complexo fluxo de comunicao representado visualmente pela figura 5.11 pode ser resumido, baseado em (FEDAK et al., 2001), atravs dos seguintes
passos:
1. O cliente solicita autenticao ao ltimo servidor com que teve contato ou ao servidor principal. Com a autenticao realizada, o servidor envia ao cliente um conjunto
100
de informaes (lista de servidores que esto aptos a distribuir tarefas, protocolo e

porta a serem utilizados para comunicao) que sero utilizadas para a realizao
das atividades;
2. Estando autenticado e com informaes suficientes para solicitar tarefas, o cliente
solicita a um dos servidores uma tarefa para computar. Para isso, o cliente envia,
junto com a requisio, informaes sobre o seu ambiente, para que o servidor
possa ento determinar a tarefa que melhor esteja adequada ao cliente;
3. O servidor retorna ento ao cliente a descrio da tarefa a ser realizada, bem como
as entradas (se aplicvel), os binrios da aplicao correspondentes ao ambiente do
cliente solicitante (baseado nas informaes recebidas no passo anterior) e o endereo do servidor que est qualificado a armazenar os resultados que sero gerados;
4. Durante o perodo em que est processando uma tarefa, o cliente envia ao servidor
mensagens indicando que o processamento est ativo. necessrio que o servidor
monitore constantemente a chegada dessas mensagens para controlar possveis timeouts. Quando um cliente (worker) permanece por muito tempo sem enviar esse
tipo de mensagem, o servidor entende que o cliente desistiu ou ficou impossibilitado
de prosseguir com o processamento e, a partir disso, a tarefa poder ser realocada
para outro cliente;
5. Por fim, quando o processamento da tarefa termina, os resultados computados so
enviados ao endereo disponibilizado ao cliente. Essa chamada ento ecoada para
o servidor de origem, que disponibilizou a tarefa geral, para sinalizar o trmino de
parte do trabalho;
6. A partir desse momento, o cliente est apto a solicitar uma nova tarefa para o(s)
servidor(es).
A comunicao entre as diferentes partes do XtremWeb pode ser feita atravs de
chamada remota de procedimentos (RPC) e transferncia direta de dados. Em linhas
gerais, segundo (CAPPELLO et al., 2005), a arquitetura de comunicao utilizada pelo
XtremWeb est fundamentada em trs camadas de protocolos. O primeiro nvel, chamado
"Conexo", dedicado a permitir comunicao entre as entidades participantes, que possam estar protegidas por um firewall, atrs de uma NAT ou mesmo via proxy. A segunda
camada, chamada "Transporte", responsvel pelo transporte das mensagens, de maneira
segura e confivel. Por fim, a terceira camada, chamada "Protocolo" responsvel por
fornecer suporte a diversos tipos e verses de APIs para RPC.
Gerenciar bloqueios impostos por firewalls a principal responsabilidade da camada
de conexo. Um firewall com uma configurao padro, tem como comportamento esperado o bloqueio de mensagens de entrada, exceto as realizadas em portas especficas e por
hosts determinados. Alm disso, geralmente, eles permitem a sada de mensagens, sem
maiores restries. Por essa preocupao, a arquitetura do XtremWeb prev a utilizao
de um componente coordenador, que pode ser visvel por outras entidades.
Por essa abordagem, os canais de comunicao nunca so iniciados pelo coordenador,
mas sim pelos clientes, workers ou qualquer outro participante. Os canais so, portanto,
usados para transmitir as mensagens de e para todos os participantes da comunicao.
Isso implica, segundo (CAPPELLO et al., 2005) que nenhum participante, exceto o coordenador, precisa ficar a frente do firewall ou com portas abertas. As comunicaes so
101
possveis se o coordenador mantiver portas dedicadas abertas e implementar protocolos

especficos. Por exemplo, JavaRMI necessita a porta rmiregistry e o XML-RPC
utiliza a porta HTTP.
5.6.3
Arquitetura
De maneira geral, a arquitetura proposta e utilizada pelo XtremWeb composta, basicamente, de trs componentes: cliente, worker e coordenador. Essa arquitetura est
adequada maioria dos projetos de computao global (INRIA, 2009). Durante a execuo, os workers buscam o servidor para busca de jobs a serem executados; em resposta,
o servidor envia um conjunto de parmetros e tambm, caso necessrio, a aplicao a
ser executada (isso acontece para as situaes onde a aplicao no esteja armazenada
no worker). Quando os workers terminarem o processamento de sua tarefa, eles acessam a figura do coordenador, para enviar os resultados, que devero ser centralizados e
armazenados. Dependendo do tamanho do resultado, a comunicao entre os workers e
o componente responsvel pela coleta de resultados pode ser feita atravs de protocolos
distintos (INRIA, 2009). Baseado em (INRIA, 2009) e (FEDAK et al., 2001), os workers
podem processar tarefas e enviar resultados com at 100 MBytes de tamanho.
XtremWeb pode tambm ser utilizado para construir sistemas centralizados de P2P.
Entretanto, de acordo com (INRIA, 2009), o XtremWeb no permite o armazenamento
de dados nos recursos de cliente e servidor. Nessa abordagem P2P, XtremWeb pode ser
utilizado da seguinte forma: tipicamente, uma ou mais aplicaes so armazenadas nos
workers. Qualquer worker pode submeter jobs, atravs do servidor P2P. Nessa abordagem, o worker ter comportamento equivalente ao cliente na arquitetura P2P. Os jobs
submetidos pelo cliente so registrados no servidor e agendados para os workers (INRIA,
2009).
Como visto anteriormente e detalhado pelo autor em (FEDAK et al., 2001), o XtremWeb
no est limitado a uma arquitetura centralizada. Novas pesquisas migram para uma soluo hierrquica. Outro fator relevante citado em (INRIA, 2009), que os workers podem
enviar os resultados diretamente aos clientes, para limitar o uso da banda de rede, no
processo de comunicao.
XtremWeb segue a viso geral de sistemas distribudos de larga escala, objetivando
tornar um conjunto de recursos no-especficos (possivelmente volteis), em um ambiente de execuo para os servios (mdulos de aplicaes, execuo ou infra-estrutura) e
oferecendo gerenciamento para a estrutura voltil.
Segundo (CAPPELLO et al., 2005), em linhas gerais, a arquitetura do XtremWeb
composta fundamentalmente quatro principais camadas. O papel da primeira camada
agregar recursos no-especficos (clusters, PCs particulares, PCs em uma rede privada e
outros) para construo de um cluster completo, mas instvel (possibilidade de nodos volteis). A segunda camada tem por objetivo tornar esse cluster instvel em uma soluo
virtual estvel. Isso feito por meio de exposio de menos recursos em relao ao nmero que realmente existe, devido ao gerenciamento de volatilidade (alguns recursos so
mantidos como recursos extras, servindo como uma espcie de backup). A terceira camada responsvel por criar uma plataforma GC genrica. Por fim, a quarta camada tem
como objetivo disponibilizar os mdulos de execuo para computao paralela, como
mestre-escravo ou ambientes MPI. Nessa arquitetura, as aplicaes dos clientes so executadas em cima da quarta camada.
Entretanto, essa arquitetura genrica de quatro camadas transformada, na prtica,
atravs da utilizao de outras sub-camadas, como apresentado na figura 5.12. Cada
102
Figura 5.12: Arquitetura de sub-camadas da plataforma XtremWeb

uma dessas sub-camadas desempenham papis e possuem responsabilidades especficas,
dentro da arquitetura do XtremWeb.
O papel da camada mais inferior (0) possibilitar o deployment do componente Launcher, que possibilita o reconhecimento de novos nodos ou recursos participantes (como
JXTA). A sub-camada (1) encapsula as infra-estruturas de comunicao, possibilitando
a troca de mensagens entre os nodos participantes e o componentes Launcher. A subcamada (2) armazena e organiza a estrutura de servios possibilitando a publicao, descoberta e construo de servios. A sub-camada (3) encapsula e define recursos e mecanismos para tolerncia a falhas. A prxima sub-camada (4) contm servios de alto-nvel
(como schedulers, repositrio de tarefas entre outros). API para computao paralela e
ambientes para runtime esto na sub-camada (5). Por fim, a sub-camada (6) contm os
servios e os binrios das aplicaes que sero executadas pelos workers.
Nas sees seguintes so apresentadas, de maneira superficial, as principais caractersticas no que diz respeito arquitetura utilizada na codificao dos workers e servidores
da plataforma.
5.6.3.1
Worker
O worker deve ser entendido como o equipamento computacional que ir ceder, de

maneira voluntria, a sua capacidade de processamento que no estiver sendo utilizada.
De acordo com (INRIA, 2009), cada worker participante tem duas funcionalidades principais:
1. Oferecer a sua capacidade de processamento ociosa, como citado anteriormente,
para a realizao de tarefas de interesse comum, disponibilizadas pelo servidor;
103
2. Executar instrues de controle, da plataforma XtremWeb, para garantir que as

tarefas a serem executadas de maneira voluntria no interfiram e atrapalhem as
atividades dos usurios, proprietrios das mquinas.
Isso significa que, para manter a aceitao dos conceitos de computao global e computao voluntria a que se vincula a plataforma, os workers foram planejados para dar
nfase no respeito do termo voluntrios (FEDAK et al., 2001). Em outras palavras, o
worker foi planejado para somente ser ativado e passar a computar tarefas, no momento
correto, ou seja, quando o recurso realmente se torna ocioso. Para isso, de acordo com
(FEDAK et al., 2001) e (INRIA, 2009), a arquitetura dos workers oferece mecanismos
para configuraes a serem feitas pelos usurios, alm de um ambiente seguro e no intrusivo.
5.6.3.1.1
Implementao
A implementao dos workers escrita, em grande parte, em Java. Entretanto, as

chamadas a instrues de funcionalidades especficas do sistema operacional so feitas
de maneira nativa, escritas em C. A comunicao entre as duas tecnologias realizada
atravs de JNI. Segundo (FEDAK et al., 2001), a escolha de Java se deu devido portabilidade da linguagem. Com isso, todo o kernel do XtremWeb pode ser facilmente portado
para diversas arquiteturas, sem a necessidade de re-escrever cdigo. Como pode ser visto
em (INRIA, 2009), os workers esto disponveis para download para plataformas Linux
Intel86 e Windows. Alm disso, (FEDAK et al., 2001) cita em sua publicao que existe
planejamento para portar os workers para PowerPC, SPARC/Solaris alm de Windows
Pocket, para poder ser executado em dispositivos mveis.
5.6.3.1.2
Arquitetura
Em termos gerais, a arquitetura de um worker na plataforma XtremWeb pode ser

dividida atravs da exemplificao de cinco componentes, como mostra a figura 5.13.
Quando o recurso est sendo utilizado pelo proprietrio, nada relacionado tarefa
da computao voluntria realizada. Isso refora a idia de que, quando no existe
recurso ocioso, nenhuma tarefa realizada e nenhum tempo extra de processamento ou
recurso de memria consumido. Nessa situao, representada pelo lado esquerdo da
figura 5.13, apenas existe um monitor de atividades rodando, com baixa prioridade. Esse
monitor de atividades existe para monitorar, como o prprio nome sugere, as atividades
desenvolvidas no recurso para buscar identificar, baseado nas restries estabelecidas pelo
usurio, o momento em que a mquina estar disponvel para computar a tarefa.
No momento em que a mquina entra em um estado disponvel para processamento
de uma tarefa, o monitor de atividades detecta e aciona um outro conjunto de threads,
representado no lado direito da figura 5.13. O principal mecanismo representado por
uma thread de controle, que mantm: uma nova thread de monitoramento, uma thread
para execuo da tarefa e uma thread de sinalizao. Com as instncias desses componentes disponveis, a situao se mantm at que atividades do usurio sejam detectadas.
A thread de monitoramento responsvel por, atravs das mtricas e restries estabelecidas pelos usurios, determinar o momento em que o recurso deixa de estar disponvel
para a grade voluntria e passa a ser de uso do usurio. A thread de execuo o mecanismo central, responsvel por processar e executar os binrios da tarefa, juntamente com
seus parmetros de entrada. A thread de sinalizao, por fim, responsvel por mandar
mensagens ao servidor indicando que o processamento est ativo e sendo executado, na
104
Figura 5.13: Arquitetura de um Worker

medida do possvel.
Essa abordagem de concentrar as threads de servio atravs de uma thread de controle
especialmente til. Com ela, em caso de o usurio retomar as atividades do recurso, a
thread central morre, levando consigo todas as threads de servio. Com isso, evitam-se
deadlocks e no existem riscos de tornar o recurso instvel.
5.6.3.2
Server
Os servidores (ou coordenadores) do XtremWeb so componentes responsveis pelo

armazenamento das aplicaes e tarefas submetidas pelos clientes. Essas aplicaes so
armazenadas na forma de binrios pr-compilados para diversas arquiteturas. Outra responsabilidade dos servidores disponibilizar, para os clientes, as tarefas e aplicaes para
serem computadas e processadas pelos workers.
A camada intermediria do XtremWeb implementa um conjunto de servios para coordenao que, segundo (CAPPELLO et al., 2005) poderia ser projetada em uma arquitetura
distribuda. Entretanto, os autores do XtremWeb decidiram implementar os servios de
maneira centralizada, por quatro motivos, conforme citado em (CAPPELLO et al., 2005):
1. Facilitar o desenvolvimento e debug do sistema;
2. Preocupaes relacionadas com performance, quando analisando comparaes entre servios
3. centralizados, hierrquicos e totalmente distribudos;
4. Incertezas tericas em relao a estrutura a ser utilizada;
Em relao s incertezas, (CAPPELLO et al., 2005) menciona que no existem resultados tericos sobre a classificao fundamental de sistemas P2P como solues distribudas. Justamente devido a essa incerteza, que no se pode decidir em relao
confiabilidade ou no no desenvolvimento desse tipo de servio de maneira distribuda.
O coordenador, no XtremWeb, composto basicamente de trs servios:
1. Repositrio de aplicaes e servios;
2. Escalonador;
3. Servidor de resultados;
105
Todos esses servios, segundo (CAPPELLO et al., 2005) trabalham em conjunto em

torno de um pool de tarefas, se mantendo sempre em um estado consistente em relao s
tarefas desenvolvidas.
O repositrio de servios e aplicaes e o scheduler implementam trs servios bsicos. O repositrio oferece um servio de publicao dos servios e aplicaes, tornandoos disponveis para os clientes, atravs das portas padres para comunicao (Java RMI,
XML-RPC). O scheduler gerencia a factory de servios atravs da criao de instncias e
aplicaes nos workers e gerencia o ciclo de vida. Segundo (CAPPELLO et al., 2005), o
scheduler implementa o modelo pull para alocao das tarefas. Isso significa que as tarefas so alocadas nos workers por demanda, de acordo com a iniciativa dos workers. Aps
o processamento da atividade ou tarefa proposta, os workers enviam os resultados processados, que so, por fim, depositados no terceiro servio oferecido pelos coordenadores: o
depsito de resultados.
Segundo (CAPPELLO et al., 2005), o papel principal do coordenador pode ser definido atravs das seguintes responsabilidades:
1. Desacoplar os clientes dos workers;
2. Coordenar a execuo das tarefas nos workers.
O coordenador aceita a requisio de tarefas de diversos clientes e as distribui, de
acordo com a poltica de escalonamento, transferindo o cdigo da aplicao (se necessrio), supervisionando a execuo das tarefas, monitorando erros ou desconexes por
parte dos workers, re-iniciando tarefas que foram interrompidas, coletando resultados de
tarefas processadas pelos workers e oferecendo os resultados finais aos clientes.
De acordo com (CAPPELLO et al., 2005), o coordenador no , necessariamente, implementado por um nodo centralizado; ele pode ser baseado em uma soluo de servios
distribudos, instalados nos nodos participantes, juntamente com outros servios.
5.6.3.2.1
Arquitetura
A arquitetura tpica de um servidor da plataforma XtremWeb composta por alguns

componentes bsicos. As sees seguintes apresentam esses componentes, detalhando
suas funcionalidades e caractersticas. Atravs da figura 5.14, possvel identificar esses
componentes, bem como a comunicao existente entre os mesmos.
Pool de Aplicaes Como descrito em (FEDAK et al., 2001), XtremWeb foca em aplicaes seqenciais, com mltiplos parmetros. A distribuio de uma aplicao consiste
em prover, aos workers, os binrios pr-compilados, de acordo com a plataforma do worker solicitante. Alm disso, necessria uma breve descrio da aplicao, uma definio
de como os parmetros devem ser interpretados e entendidos pelos workers alm da especificao dos resultados que so esperados. Para todo esse armazenamento, alm do
controle de verso e upgrades das aplicaes disponibilizadas, o pool de aplicaes
utilizado.
Pool de Jobs Um cliente pode submeter uma tarefa para o XtremWeb atravs da disponibilizao de uma referncia aplicao e um conjunto de parmetros que caracteriza
o job a ser executado. Parmetro, de acordo com (FEDAK et al., 2001), pode ser diversos arquivos, leitura atravs da entrada padro ou argumentos passados pela linha de
comando. Atravs do pool de jobs feito o armazenamento das tarefas. Quando uma
tarefa armazenada na base de dados do XtremWeb, ela recebe um identificador nico,
que ser utilizado para referenciar a tarefa, nos diversos componentes da arquitetura.
106
Figura 5.14: Arquitetura de um Servidor

Mdulo de Accounting o mdulo responsvel por gerenciar e executar o processo
de armazenamento das informaes sobre as tarefas. Essas informaes so: a referncia
para o host que executou a tarefa (ou lista de hosts, caso interrupes tenham ocorrido),
o identificador do cliente que submeteu a tarefa e diversas outras informaes de data e
tempo, relacionadas com as execues.
5.6.3.2.2
Implementao
A implementao do servidor do XtremWeb utiliza, na maior parte do seu cdigo, solues livres, disponveis na maior parte dos sistemas operacionais modernos. A principal
linguagem utilizada no desenvolvimento Java, que garante, invariavelmente, a portabilidade da soluo.
Na verso original da plataforma, MySql utilizado como base de dados para armazenamento das informaes e configuraes. Entretanto, a maior parte das linguagens
utilizadas para desenvolver o servidor (Java, PHP e Perl), oferecem bases de dados de
acesso direto (como por exemplo, Java Database Connectivity ou Perl Database Interface). Isso oferece a possibilidade de troca para outro mecanismo de armazenamento,
sem a necessidade de modificar ou realizar ajustes no cdigo da aplicao.
A implementao do servidor oferece ainda aos clientes e administradores, de acordo
com (FEDAK et al., 2001), uma interface web para permitir maior iterao com o sistema.
Atravs dela, permitida a submisso de tarefas, acompanhamento do andamento dos
processos (jobs) e recebimento dos resultados, entre outros recursos.
5.7
Modificaes Propostas no Worker
Para que o mecanismo de checkpoint proposto seja utilizado, tendo como enfoque recursos com perodos de disponibilidade curtos, porm freqentes, o worker do XtremWeb
precisa sofrer algumas pequenas modificaes. Essas modificaes dizem respeito maneira como o status de atividade do recurso deve ser monitorado, alm da maneira como
o processamento da aplicao-alvo deve ser inicializado e interrompido.
Anteriormente, nesse mesmo captulo, foram apresentados os mecanismos para inicializao e interrupo de aplicaes, disponibilizados pelo modelo de checkpoint proposto. Essas informaes devem ser aplicadas ao worker da plataforma de computao
voluntria para qual o prottipo foi pensado.
O projeto de soluo descrito na seqencia desse captulo apresenta as modificaes
necessrias no activator model e tambm as alteraes previstas para a inicializao e
107
Figura 5.15: Activator Model do XtremWeb

interrupo da execuo voluntria. Esse projeto tem como base a utilizao do modelo
de checkpoint implementado pelo prottipo acima, sendo utilizado para um modelo de
worker da plataforma XtremWeb.
5.7.1 Activator Model
O modelo de activators presente no worker do XtremWeb pode ser representado pelo
diagrama de classes mostrado na figura 5.15. As subclasses do Activator so utilizadas para monitorar a atividade no worker. Esse monitoramento pode ser feito por cinco
classes distintas, mais o activator criado especificamente para o modelo proposto.
5.7.1.1 DateActivator
Essa abordagem permite que o processamento do worker seja ativado baseado em
informaes de data e hora, seguindo um modelo parecido com a crontab. Isso significa
que, atravs da utilizao do DateActivator, possvel determinar datas e horrios
especficos onde as atividades de processamento voluntrio, realizado pelo worker, podem
ser iniciadas.
5.7.1.2 MouseKbdActivator
A utilizao do MouseKbdActivator permite a realizao do monitoramento das
atividades de mouse e teclado do dispositivo onde o worker est instalado. Atravs desse
activator, aes sobre o mouse e o teclado so monitoradas para, caso aconteam, permitirem que o processamento voluntrio seja interrompido. A utilizao do mouse ou do
108
teclado pelo proprietrio do recurso indica, invariavelmente, que o mesmo deseja retomar o controle de execuo do seu equipamento, o que indica que todo processamento
voluntrio em execuo deva ser interrompido.
5.7.1.3 CpuActivator
De maneira equivalente aos activators j apresentados, essa soluo oferece o monitoramento das atividades da CPU onde o worker est instalado. Atravs dela, possvel
identificar se as atividades de processamento do worker podem ser iniciadas ou no, baseado na utilizao da CPU.
5.7.1.4 Activators de Proteo de Tela
O modelo de activators do XtremWeb oferece dois mecanismos para verificar o estado
das proteo de tela do recurso voluntrio. Esses activators so responsveis por verificar
se a proteo de tela est sendo executada. Caso a proteo de tela esteja em execuo,
significa que o equipamento no est em uso pelo proprietrio e, portanto, se apresentam
como opes para o processamento voluntrio. A partir dessa informao, o worker tem
condies de avaliar se a aplicao-alvo pode ser executada ou no.
Por padro, o modelo de activators oferece duas solues nesse sentido:
5.7.1.4.1 WinSaverActivator
Activator que monitora a presena de proteo de tela em execuo para ambientes
Windows.
5.7.1.4.2 MacSaverActivator
Activator que monitora a presena de proteo de tela em execuo para ambientes
Mac OS X.
5.7.1.5 SNMPActivator
Dos diversos estados que uma impressora pode apresentar, alguns se tornam mais interessantes para o modelo que deseja-se implementar. Para aplicar um modelo de checkpoint dentro de um worker que se prope a ser instalado dentro de uma multifuncional, o
modelo de activators precisa ser ampliado para contemplar uma nova especializao.
Essa nova proposta obtida atravs da observao do status geral da impressora, atravs de operaes de SNMP. SNMP pode ser definido, de acordo com (TELECOM, 2009)
como um protocolo de gerncia tpica de redes TCP/IP, da camada de aplicao, que facilita o intercmbio de informao entre os dispositivos de rede. O SNMP possibilita
aos administradores de rede gerenciar o desempenho da rede, encontrar e resolver seus
eventuais problemas, e fornecer informaes para o planejamento de sua expanso.
O activator proposto pelo modelo faz uso de operaes SNMP locais para verificar o
status da impressora, indicando se o processamento das atividades voluntrias pode prosseguir ou se deve ser interrompido. A RFC 1759 (RFC, 2009) define os objetos SNMP
que devem estar disponveis em impressoras para que estas estejam em conformidade com
os padres esperados pelo mercado.
A RFC 1759 define trs objetos que podem ser utilizados em conjunto ou individualmente para obter o estado geral da impressora. A tabela 5.5 mostra os objetos
hrDeviceStatus, hrPrinterStatus e hrPrinterDetectedErrorState
e alguns dos seus possveis significados:
109

Status
hrDeviceStatus hrPrinterStatus hrPrinterDetectedErrorState
Normal
running
idle
sem informao
Busy ou Indisponvel
running
printing
sem informao
Alerta no-crtico
warning
idle ou printing
lowPaper, lowTonner, ...
Alerta crtico
down
outro
jammed, noPaper, noToner,...
Indisponvel
down
outro
sem informao
Offline
warning
idle ou printing
sem informao
Para o modelo de checkpoint proposto, as informaes de estado fornecidas para o objeto hrPrinterStatus so as que mais interessam na montagem do activator. Ainda
de acordo com a RFC1759, o objeto hrPrinterStatus tem a seguinte especificao:
Listing 5.13: RFC 1759 - Printer MIB
1
2
3
4
5
6
7
8
9
10
11
12
13
hrPrinterStatus OBJECTTYPE
SYNTAX INTEGER {
other ( 1 ) ,
unknown ( 2 ) ,
idle ( 3 ) ,
printing ( 4 ) ,
warmup ( 5 )
}
ACCESS readonly
STATUS mandatory
DESCRIPTION
" The c u r r e n t s t a t u s o f t h i s p r i n t e r d e v i c e . When i n t h e i d l e ( 1 ) , p r i n t i n g ( 2 ) , o r warmup ( 3 ) s t a t e , t h e c o r r e s p o n d i n g h r D e v i c e S t a t u s s h o u l d be r u n n i n g ( 2 ) o r w a r n i n g ( 3 ) . When i n t h e unknown s t a t e , t h e c o r r e s p o n d i n g h r D e v i c e S t a t u s s h o u l d be unknown ( 1 ) . "
: : = { hrPrinterEntry 1 }
Dessa forma, a classe SNMPActivator deve observar o objeto hrPrinterStatus

e somente permitir a execuo das atividades da aplicao-alvo quando o resultado das
operaes de SNMPget foram iguais a idle(3). Dessa forma, o worker instalado na
multifuncional ser capaz de monitorar a atividade da impressora e utilizar a capacidade
de processamento do recurso para o ambiente de computao voluntria.
Para isso, o mtodo protected boolean canStart() realiza operaes de
SNMPget no objeto hrPrinterStatus retornando true caso o valor retornado seja
igual a 3. Da mesma forma, o mtodo protected boolean mustStop() responde com true caso o valor de retorno da operao de SNMP seja diferente de 3.
5.7.2
Adaptando ThreadLaunch
A classe ThreadLaunch, no worker do XtremWeb, tambm sofre adaptaes para

permitir a utilizao do mecanismo de checkpoint proposto. Essa thread possui um looping infinito que responsvel por aguardar o momento em que o processamento voluntrio permitido, baseado na poltica definida. Quando um perodo adequado para o
processamento voluntrio encontrado, a ThreadLaunch responsvel por retomar a
execuo das atividades voluntrias no recurso em que est instalada. Tambm responsabilidade desse componente identificar o momento em que a computao voluntria no
mais permitida e suspender toda e qualquer atividade nesse contexto.
Como mostra o diagrama de classe representado pela figura 5.2, essa classe utiliza
110
Figura 5.16: Diagrama de Classes da ThreadLaunch

um conjunto de objetos do tipo Activator para realizar o monitoramento do estado do
recurso. Esse monitoramento, no caso do modelo proposto, deve ser realizado utilizando
o SNMPActivator, descrito anteriormente.
Com o monitoramento da utilizao do recurso controlado, a execuo da aplicao
pode ento ser iniciada atravs da classe MainFacade, do componente de checkpoint
descrito. Dessa forma, a execuo da aplicao ser iniciada considerando o modelo de
prevalncia, possibilitando o armazenamento das informaes intermedirias produzidas.
A interrupo da execuo tambm passa a ser realizada adicionando a chamada para a
classe MainFacade
5.8
Consideraes Finais
Esse captulo detalhou a implementao do modelo de soluo baseado na proposta

apresentada nessa dissertao, para permitir a realizao de operaes de checkpoint em
memria atravs da prevalncia de objetos. Alm do detalhamento do mecanismo de
checkpoint proposto, esse captulo viabilizou o estudo em detalhes do worker da plataforma XtremWeb, fazendo com que suas principais caractersticas e componentes fossem
detalhados.
Com a arquitetura do modelo de checkpoint apresentada e seus componentes detalhados, o presente captulo tambm apresentou as abordagens e premissas que devem ser
observadas para a utilizao do modelo. Nesse sentido, aplicaes-modelo foram utilizadas para exemplificar a aplicabilidade prtica do modelo de checkpoint proposto.
Com a implementao do mecanismo de checkpoint proposto e tendo como base os
estudos realizados em cima do worker da plataforma de computao voluntria escolhida,
foi possvel detalhar o projeto para utilizao do componente criado, dentro da plataforma
em questo.
Este captulo tambm permitiu a observao e o detalhamento da utilizao de impressoras multifuncionais. Esse tipo de recurso, at ento descartado como equipamento v-
111
lido para participao em ambientes de computao voluntria, foi estudado tendo como
objetivo permitir avaliar com segurana a sua disponibilidade e capacidade de produzir
resultados vlidos, para esse tipo de ambiente oportunstico.
112
APLICAO DO MODELO E DESEMPENHO
A implementao do modelo de checkpoint com prevalncia de objetos descrito no

captulo anterior foi analisada, em um primeiro momento, de maneira terica, descrevendo os principais componentes e decises de projeto. Em uma segunda etapa, torna-se
interessante avaliar o modelo de uma maneira emprica. Essa validao foi feita atravs
da utilizao de uma aplicao real, fato que permitiu que fossem observados detalhes de
implementao e overheads adicionados aplicao original, quando da sua execuo em
um ambiente prevalente. Uma aplicao foi executada sem modificaes e os resultados
obtidos a partir dessa medio foram comparados a execues de uma verso modificada,
adaptada ao modelo prevalente com os recursos de checkpoint. Nesse sentido, esse captulo apresenta a validao do prottipo do mecanismo de checkpoint implementado, para
uma aplicao real, validando os principais fatores que podem ser determinantes para a
utilizao ou no do modelo de checkpoint.
6.1
Aplicao-alvo
Para validar a aplicao do modelo de checkpoint e possibilitar que resultados de

desempenho fossem obtidos, optou-se por utilizar uma implementao da aplicao de
n-gramas. A aplicao em questo tem por objetivo identificar a usabilidade de determinadas palavras, dentro de um determinado idioma, atravs da utilizao de mecanismos
de busca na internet. De acordo com (YAMAMOTO et al., 2001), n-gramas so amplamente utilizados como um modelo estatstico para processamento de linguagem, que
permite identificar a probabilidade de utilizao de determinado termo. No objetivo
dessa medio, validar se a aplicao est correta, nem mesmo avaliar os resultados obtidos a partir da sua execuo; apenas de interesse verificar o comportamento da mesma
quando executada dentro de um modelo de checkpoint prevalente.
6.1.1
Cdigo Original
A implementao original do programa que busca pela utilizao de n-gramas pode

ser vista na listagem abaixo. O algoritmo bsico implementado por essa aplicao, considera como entrada um arquivo texto onde cada linha representa um n-grama a ser pesquisado. Ao ser inicializada, a aplicao utiliza esse arquivo de entrada e conecta ao servio
fornecido pelo yahoo para verificar o nmero de ocorrncias do resultado.
Listing 6.1: Aplicao N-Gramas Original
1
2
i m p o r t com . yahoo . search . ;

i m p o r t java . io . ;
113
3
4
5
6
7
8
9
10
p u b l i c c l a s s NGramas {
p r i v a t e s t a t i c f i n a l String DEFAULT_ID = " ngram001 " ;
p r i v a t e s t a t i c f i n a l i n t DEFAULT_SIZE = 5 0 0 0 ;
p r i v a t e s t a t i c f i n a l i n t DEFAULT_OFFSET = 0 ;
p r i v a t e s t a t i c f i n a l String DEFAULT_LANG = " en " ;
p r i v a t e s t a t i c f i n a l BufferedReader DEFAULT_INPUT = new BufferedReader ( new InputStreamReader ( System . in ) ) ;
p r i v a t e s t a t i c BufferedReader in = DEFAULT_INPUT ;
p r i v a t e s t a t i c String clientId = DEFAULT_ID ;
p r i v a t e s t a t i c i n t size = DEFAULT_SIZE , offset = DEFAULT_OFFSET , count = 1 ;
p r i v a t e s t a t i c String lang = DEFAULT_LANG ;
p r i v a t e s t a t i c File input ;
p r i v a t e s t a t i c SearchClient client ;
p r i v a t e s t a t i c WebSearchRequest request ;
p r i v a t e s t a t i c WebSearchResults results ;
11
12
13
14
15
16
17
18
19
20
21
22
p r i v a t e v o i d processArguments ( ) {
try {
input = new File ( " / home / r a f a e l / M e s t r a d o / BaseCode / C h e c k P r e v a l e n t / s r c / ngramlist . txt " ) ;
in = new BufferedReader ( new InputStreamReader ( new FileInputStream ( input) ) );
} c a t c h ( FileNotFoundException fnfEx ) {
System . err . println ( " E r r o r i n t h e i n p u t f i l e : \ n " + fnfEx . getMessage ( ) ) ;
System . exit ( 1 ) ;
}
}
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
p r i v a t e v o i d offsetYahoo ( ) {
client = new SearchClient ( clientId ) ;
request = new WebSearchRequest ( " Empty " ) ;
request . setType ( " p h r a s e " ) ;
request . setLanguage ( lang ) ;
request . setResults ( 0 ) ;
}
p r i v a t e v o i d search ( ) {
String line = " " ;
try {
line = in . readLine ( ) ;
} c a t c h ( IOException ioEx ) {
System . err . println ( " E r r o r on r e a d i n g from i n p u t : \ n " + ioEx . getMessage ( ) ) ;
}
w h i l e ( line ! = n u l l && ! line . equals ( " " ) ) {
try {
i f ( count > offset && count <= offset + size ) {
request . setQuery ( line ) ;
results = client . webSearch ( request ) ;
System . out . println ( line + " " + results . getTotalResultsAvailable() ) ;
}
count++;
} c a t c h ( Exception e ) {
System . err . println ( " E x c e p t i o n c a u g h t . " ) ;
System . err . println ( e . getMessage ( ) ) ;
}
}
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
}
p u b l i c s t a t i c v o i d main ( String [ ] args ) {
NewClass obj = new NewClass ( ) ;
obj . processArguments ( ) ;
obj . offsetYahoo ( ) ;
obj . search ( ) ;
}
}
114
6.1.2
Modificaes
Como citado no captulo que descreve o modelo de checkpoint proposto, a aplicao a ser executada dentro desse contexto precisa sofrer algumas modificaes. A primeira modificao a ser realizada alterar a definio da classe para estender a classe
ApplicationFacade e implementar a interface ITargetApplication, como
feito na linha 6 da listagem abaixo. A partir dessa modificao, o mtodo main deve
ser alterado conforme mostra a linha 69, para determinar ao mecanismo de checkpoint
o ponto de incio da aplicao. Alm disso, o mtodo InitializeProgram definido na linha 25, a varivel StartupValue inicializada de acordo. Por fim, a linha 58
mostra a chamada ao mtodo PrevalentExecution, que possibilita aos dados produzidos serem encapsulados ao modelo de prevalncia. Esse conjunto de modificaes
pode ser observado na listagem de cdigo abaixo.
Listing 6.2: Aplicao N-Gramas Modificada

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
import
import
import
import
Checkpoint . TargetExtension . ApplicationFacade ;

Checkpoint . TargetExtension . ITargetApplication ;
com . yahoo . search . ;
java . io . ;
p u b l i c c l a s s NGramas e x t e n d s ApplicationFacade i m p l e m e n t s ITargetApplication
p r i v a t e s t a t i c f i n a l String DEFAULT_ID = " ngram001 " ;

p r i v a t e s t a t i c f i n a l i n t DEFAULT_SIZE = 5 0 0 0 ;
p r i v a t e s t a t i c f i n a l i n t DEFAULT_OFFSET = 0 ;
p r i v a t e s t a t i c f i n a l String DEFAULT_LANG = " en " ;
p r i v a t e s t a t i c f i n a l BufferedReader DEFAULT_INPUT = new BufferedReader ( new InputStreamReader ( System . in ) ) ;
p r i v a t e s t a t i c BufferedReader in = DEFAULT_INPUT ;
p r i v a t e s t a t i c String clientId = DEFAULT_ID ;
p r i v a t e s t a t i c i n t size = DEFAULT_SIZE , offset = DEFAULT_OFFSET , count = 1 ;
p r i v a t e s t a t i c String lang = DEFAULT_LANG ;
p r i v a t e s t a t i c File input ;
p r i v a t e s t a t i c SearchClient client ;
p r i v a t e s t a t i c WebSearchRequest request ;
p r i v a t e s t a t i c WebSearchResults results ;
p r i v a t e File testFile = new File ( " / home / r a f a e l / M e s t r a d o / BaseCode / C h e c k P r e v a l e n t / src / ngramlist . txt " ) ;
p r i v a t e BufferedReader StartupValue ;
p u b l i c v o i d initializeProgram ( ) {
try {
StartupValue = new BufferedReader ( new FileReader ( testFile ) ) ;
} c a t c h ( FileNotFoundException fnf ) { }
};
p r i v a t e v o i d processArguments ( ) {
in = StartupValue ;
}
p r i v a t e v o i d offsetYahoo ( ) {
client = new SearchClient ( clientId ) ;
request = new WebSearchRequest ( " Empty " ) ;
request . setType ( " p h r a s e " ) ;
request . setLanguage ( lang ) ;
request . setResults ( 0 ) ;
}
p r i v a t e v o i d search ( ) {
String line = " " ;
try {
} c a t c h ( IOException ioEx ) {
System . err . println ( " E r r o r on r e a d i n g from i n p u t : \ n " + ioEx . getMessage ( ) ) -
115
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
;
}
w h i l e ( line ! = n u l l && ! line . equals ( " " ) ) {
try {
i f ( count > offset && count <= offset + size ) {
request . setQuery ( line ) ;
results = client . webSearch ( request ) ;
String tmp = line + " " + results . getTotalResultsAvailable ( ) ;
System . out . println ( tmp ) ;
t h i s . PrevalentExecution ( tmp ) ;
}
count++;
} c a t c h ( Exception e ) {
System . err . println ( " E x c e p t i o n c a u g h t . " ) ;
System . err . println ( e . getMessage ( ) ) ;
}
}
}
p u b l i c v o i d start ( ) {
processArguments ( ) ;
offsetYahoo ( ) ;
search ( ) ;
}
}
6.2
Ambiente de Execuo
A aplicao-alvo descrita anteriormente foi executada dentro de um ambiente que

simula uma impressora multifuncional com 800MHz de capacidade de processamento
e 768 MB de memria. Nesse ambiente onde o experimento foi executado, Microsoft
Windows utilizado como sistema operacional, rodando a verso 1.4 da plataforma Java.
O mecanismo de checkpoint proposto foi instalado nesse ambiente, juntamente com
a aplicao-alvo descrita acima. Para possibilitar a interrupo e reincio das atividades,
foi instalada tambm uma aplicao grfica simples. Atravs dela, qualquer aplicao
adaptada ao modelo do checkpoint pode ser executada e interrompida - essa aplicao somente til para facilitar a realizao dos testes. Para os testes aqui descritos, a aplicao
n-gramas foi utilizada conforme descrito nos cenrios.
Os resultados foram obtidos atravs da utilizao da ferramenta de profiler da IDE
Netbeans. A execuo da aplicao original e da aplicao alvo foi observada e monitorada atravs dessa ferramenta, que se apresenta como uma soluo interessante para
obteno de informaes durante o runtime da aplicao. Segundo (NETBEANS, 2009),
o profiler permite monitorar, com baixo overhead, informaes referentes ao estado das
threads em execuo, alm do desempenho da CPU e utilizao de memria.
6.3
Cenrios de Testes
O conjunto de testes realizados para a medio do desempenho do modelo pode ser

dividido em duas etapas. A primeira delas a execuo simples da aplicao n-gramas,
sem nenhuma modificao referente ao modelo de checkpoint. A segunda etapa contempla a execuo da mesma aplicao, dentro do conceito de checkpoint com prevalncia
proposto. Para a terceira etapa, foram realizadas medies referentes execuo da aplicao dentro do modelo de checkpoint proposto, contemplando a atividade de recuperao
das informaes intermedirias produzidas. As medies realizadas na aplicao original
116
so teis quando comparadas s medies realizadas na aplicao modificada, para medir

o overhead adicionado quando deseja-se utilizar o mecanismo de checkpoint.
Para essas trs etapas, foram verificadas as seguintes informaes:
1. Desempenho do garbage collector;
2. Utilizao de memria;
3. Desempenho para realizao de snapshots;
4. Tamanho das informaes geradas em disco;
5. Hotspots1 da aplicao.
Os cenrios descritos foram realizados utilizando intervalos de tempo de dois minutos. Isso significa que a aplicao original (para a primeira etapa de testes) e a aplicao
modificada (para a segunda e terceira etapas) foram executadas durante dois minutos e
interrompidas. Nessa abordagem, dentro do modelo modificado, a aplicao foi executada dentro do modelo de checkpoint com prevalncia por dois minutos e interrompida.
Quando da execuo do terceiro cenrio, os valores produzidos pela segunda etapa so
recuperados e o reincio adequado para que valores intermedirios sejam utilizados.
6.4
Resultados Obtidos
Para verificar a usabilidade do modelo de checkpoint com prevalncia de objetos proposto nessa dissertao, uma aplicao real foi submetida execuo dentro do conceito
proposto. Essa execuo foi monitorada por uma ferramenta de perfilamento, de onde
diversas informaes puderam ser extradas e analisadas.
A primeira informao avaliada foi a utilizao de memria, para verificar se a utilizao do mecanismo de checkpoint poderia causar danos sensveis ou at mesmo a quebra
da execuo da aplicao atravs de exceptions. De maneira relacionada utilizao da
memria, foi observada a realizao de chamadas ao processo de garbage collector, para
verificar possveis memory leaks e alocao indevida de objetos em memria. Alm dos
conceitos relacionados com memria, foi medido o overhead total de execuo adicionado pelo modelo de checkpoint aplicao original, alm do tamanho das informaes
produzidas e armazenadas em disco pelo mecanismo de checkpoint proposto. Essas informaes foram medidas para a aplicao original, sem modificaes e para a verso
adaptada ao modelo de checkpoint com prevalncia de objetos. Os resultados obtidos por
essas medies foram comparados e as concluses descritas nas sees abaixo.
6.4.1
Utilizao de memria heap
Um conceito importante de ser monitorado quando desenvolvemos aplicaes, em

especial em Java, a alocao de objetos em memria. Quando a mquina virtual do Java
inicia a sua execuo, ela aloca uma quantidade pr-estabelecida de espao para memria
heap. Conforme a aplicao executada, objetos so criados e armazenados dentro desse
espao e, quando no so mais necessrios, o garbage collector do Java elimina essas
informaes, recuperando o espao para ser novamente utilizado.
1
Por hotspot devemos entender como o local da aplicao onde o maior nmero de instrues foi executada ou o local onde o desempenho foi mais prejudicial, em termos de tempo, durante a execuo do
programa.
117
Como base nisso, o conceito de espao livre em memria para aplicaes Java pode ser
definido como a quantidade de memria que foi alocada e ainda est disponvel para uso.
Quando essa quantidade de memria livre se aproxima de zero, as frequentes chamadas
ao processo de garbage collector passam a impactar a execuo normal da aplicao,
em termos de performance. Quando o espao alocado termina, ou seja, a quantidade de
memria disponvel igual a zero, a JVM assinala que no mais possvel criar novos
objetos, levantando uma exceo de out of memory. Como resultado visvel disso, o
sistema deixa de ser executado e a aplicao em questo interrompida.
Abaixo so apresentadas as medies de utilizao de memria heap para a aplicaomodelo original e para a aplicao modificada para o conceito de checkpoint. Os grficos
mostram, durante o tempo de execuo da aplicao, o comportamento referente utilizao da memria por parte da aplicao. O aspecto a ser avaliado a diferena entre
as duas aplicaes, para verificar o impacto adicionado pelo modelo de checkpoint em
relao aplicao original.
O contexto de execuo tanto da aplicao original quanto da aplicao modificada
tem 5MB de memria alocada. Essa informao representada pelo layer vermelho nos
grficos da figura 6.1(a) e 6.1(b). O grfico 6.1(a) representa a quantidade de memria
que foi efetivamente alocada para a execuo da aplicao original. Ao longo do tempo
em que a aplicao estava rodando, a utilizao mxima de memria para alocar os objetos
criados para a aplicao no chegou na marca de 3.5MB.
A aplicao modificada foi executada dentro do mesmo contexto, com a mesma durao de execuo. O grfico 6.1(b) mostra as informaes de alocao de memria para a
aplicao-modificada.
Comparando os grficos de alocao de memria heap dos dois cenrios de execuo,
possvel verificar que a utilizao do modelo de checkpoint com prevalncia adiciona
um pequeno overhead em termos de quantidade de memria alocada. Essa informao
esperada e aceitvel, uma vez que os resultados intermedirios produzidos so mantidos
em memria, para uma eventual recuperao futura.
(a) Memria da Aplicao Original
6.4.2
(b) Memria da Aplicao Modificada
Desempenho do garbage collector
Como citado anteriormente, a utilizao do garbage collector fundamental para

aplicaes Java, a fim de remover objetos alocados em memria que no possuem mais
referncias e, portanto, no so mais utilizados pela aplicao. Entretanto, a utilizao de
chamadas frequentes ao GC causam overhead no desempenho da aplicao e devem ser
minimizadas.
O desempenho do GC para a aplicao original e para a modificada foi avaliado sob
dois conceitos: a primeira medio avalia o tempo necessrio para a execuo do processo
de GC e a segunda medio mostra o nmero de objetos que sobrevivem ao processo de
GC. A informao da primeira medio nos mostra o tempo que adicionado execuo
118
normal da aplicao, para que o processo de GC possa ser realizado no sistema. J a

segunda medio mostra a quantidade de objetos alocados em memria que sobrevivem
ao processo de GC. Essa segunda informao especialmente importante pois possibilita verificar o crescimento da quantidade de objetos alocados em memria ao longo da
execuo da aplicao.
O grfico 6.1(c) mostra a utilizao das operaes do processo de garbage collector
para a aplicao original. Atravs da anlise sobre esse grfico, possvel verificar que
o tempo das operaes do garbage collector no impacta sobre o processamento da aplicao. Entretanto, possvel verificar que a aplicao modelo avaliada apresenta uma
situao que configura um potencial memory leak, posto que a quantidade de objetos alocados cresce gradativamente ao longo da execuo.
A aplicao modificada, quando executada dentro do mesmo contexto, apresenta o
comportamento descrito no grfico 6.1(d). De maneira semelhante ao comportamento
da aplicao original, a aplicao executada dentro do modelo de checkpoint proposto
no apresenta chamadas ao garbage collector que possam influenciar no desempenho de
execuo da aplicao. Da mesma forma, o comportamento de possuir uma quantidade
crescente de objetos alocados permanece, da mesma forma que na aplicao original.
Entretanto, importante destacar que a quantidade de objetos nessa condio permanece
inalterado. Isso significa que o mecanismo de checkpoint em si, no est introduzindo
problemas de memory leak para as aplicaes.
(c) Utilizao GC da Aplicao Original
(d) Utilizao GC da Aplicao Modificada
Comparando os grficos 6.1(c) e 6.1(d), possvel inferir que o comportamento em

relao utilizao do garbage collector e da quantidade de objetos alocados em memria ao longo da execuo semelhante para a aplicao original e para a modificada.
Dessa forma, correto afirmar que as aplicaes que optarem por utilizar o mecanismo
de checkpoint proposto no iro sofrer impactos em termos de utilizao de operaes de
garbage collector, nem mesmo tero objetos desnecessrios alocados em memria.
6.4.3
Realizao de Snapshots
O processo de realizao de snapshots peridicos importante para permitir que as

informaes intermedirias produzidas possam ser armazenadas em meio fsico, evitando
que os resultados sejam perdidos em caso de falhas. Esse processo realizado de maneira
peridica, dentro de um intervalo de tempo pr-estabelecido e configurado no mecanismo
de checkpoint. Entretanto, a realizao desse processo de armazenamento em disco envolve a serializao das informaes e, como visto ao longo dessa dissertao, a operao
de IO pode se apresentar como gargalo para a aplicao.
6.4.3.1
Criao de um snapshot
Com o objetivo de identificar o custo associado realizao do processo de checkpoint

em disco, a execuo dos mtodos envolvidos foi monitorada e apresentada abaixo. A
119
Figura 6.1: rvore de Chamadas do checkpoint Peridico

aplicao original no apresenta essa estatstica pois ela no est encapsulada no conceito de checkpoint com prevalencia de objetos e, portanto, no possui um mecanismo de
checkpoint peridico em disco associado.
A figura 6.1 apresenta a estrutura para a chamada do processo de execuo peridica
de snapshots. Atravs dessa medio, possvel verificar que o tempo total para execuo do mtodo que realiza um snapshot de 187ms. Esse valor deve ser entendido
como o tempo que ser adicionado ao tempo normal da aplicao, para que os resultados
intermedirios produzidos e residentes em memria possam ser serializados em disco.
6.4.3.2
Informaes em disco
Como detalhado no captulo anterior sobre o modelo de checkpoint proposto por essa
dissertao, em intervalos de tempo configurados pelo administrador do sistema, execues de checkpoints em disco peridicas so realizadas. Quando a execuo de um
snapshot realizada, as informaes intermedirias produzidas so serializadas em disco.
Esse processo envolve a criao de arquivos em disco que podem ter seu tamanho aumentado, de acordo com a quantidade de informaes produzidas. O tamanho do arquivo est
diretamente relacionado com o intervalo de checkpoint utilizado. Isso significa que quanto
maior o tempo de intervalo utilizado, mais informaes so produzidas e armazenadas em
memria e, por conseqncia, maior a quantidade de informaes serializadas.
Para verificar o comportamento relacionado com as operaes de snapshot, o tamanho
fsico dos arquivos produzidos em disco foi observado ao longo da execuo da aplicao.
Ao longo da execuo da aplicao, as operaes de snapshot so realizadas e os dados at
ento produzidos so serializados em disco. A medida que a execuo transcorre, mais
resultados so produzidos e, por consequencia, maiores ficam os arquivos de snapshot
produzidos.
O grfico 6.2 permite ter uma idia das informaes produzidas em disco, quando
a aplicao n-gramas modificada executada dentro do contexto anteriormente citado.
Para essa medio, o intervalo de tempo configurado para a realizao de snapshots foi
de 30 segundos. Isso significa que a cada 30 segundos, as informaes armazenadas na
memria foram serializadas para disco.
6.4.3.3
Recuperao das Informaes
Essas informaes produzidas em disco so especialmente importantes quando a execuo normal do equipamento interrompida devido a falhas. Nessas situaes, ao ser
retomada a execuo de uma atividade voluntria, o mecanismo de checkpoint proposto
procura por informaes j produzidas para retomar a execuo. De acordo com o deta-
120
Figura 6.2: Tamanho Fsico do Snapshot em Disco
Figura 6.3: Tempo de execuo para recuperao de snapshots
lhamento oferecido no captulo sobre o modelo, o primeiro local onde as informaes intermedirias so produzidas em memria, sendo seguida por uma busca em disco. Dessa
forma, torna-se interessante medir no s o tempo para realizar o snapshot e o tamanho
das informaes produzidas em disco, mas tambm o tempo necessrio para buscar essas
informaes e recuper-las em memria para serem, de fato, novamente teis ao modelo.
Dessa forma, foi medido o tempo necessrio para recuperar o arquivo de snapshot do
disco e realizar as devidas operaes de deserializao, recuperando as informaes intermedirias produzidas e reposicionando o incio da aplicao no ltimo resultado vlido
produzido.
Na imagem 6.3 possvel verificar que o tempo transcorrido para que os snapshots
produzidos fossem recuperados do disco e realocados em memria, estando disponveis
para sua efetiva utilizao na aplicao em questo, causam um overhead de 63.5ms.
121
Figura 6.4: Hotspots da Aplicao Original

6.4.4 Hotspots das Execues
Como visto anteriormente, para que seja possvel a utilizao do conceito de checkpoint com prevalncia de objetos proposto nessa dissertao, algumas modificaes devem ser realizadas na aplicao original. Essas modificaes, detalhadas anteriormente
nesse mesmo captulo, poderiam causar overhead prejudicando o desempenho da aplicao.
Para verificar possveis danos causados ao desempenho da aplicao, os principais
hotspots da aplicao original foram medidos. Da mesma forma, a execuo dos mtodos
da aplicao adaptada foi observada. A partir dos dados obtidos, possvel realizar uma
comparao das execues que possibilita avaliar o tempo (overhead) adicionado pelo
mecanismo de checkpoint proposto aplicao original.
A imagem 6.4 mostra os mtodos executados pela aplicao original e seus respectivos
tempos de execuo. Observando esses valores, possvel perceber que apenas instrues
de negcio da aplicao so executados.
Nessa mesma linha, a imagem 6.5 mostra os hotspots de execuo da aplicao modificada. Atravs da anlise dessas informaes, possvel identificar que o tempo de execuo da aplicao original sofreu modificaes, devido aos novos mtodos responsveis
pela manuteno de prevalncia das informaes. Isso significa que, alm dos mtodos
mostrados na imagem 6.4, novas instrues foram realizadas, o que gera um acrscimo
de tempo na execuo da aplicao.
6.5
Consideraes Finais
O captulo de aplicao do modelo e desempenho apresentou uma avaliao emprica

de uma aplicao real, dentro do modelo de checkpoint proposto. Para que esse objetivo
fosse atingido, foi utilizada uma aplicao bag-of-tasks bastante utilizada para pesquisa
e processamento de linguagem natural, que utiliza mecanismos de busca na internet para
verificar a utilizao de termos idiomticos. Essa aplicao original foi executada dentro
de um ambiente restrito em termos de memria, disco e processamento e teve seus principais conceitos avaliados. Da mesma forma, foram realizadas pequenas adaptaes na
aplicao utilizada, para que esta pudesse estar adaptada ao modelo de checkpoint com
prevalncia de objetos proposto. A aplicao modificada foi realizada dentro do mesmo
contexto de execuo, tendo as mesmas informaes capturadas e comparadas s informaes originais.
Como foi visto nas medies apresentadas, o tempo para o armazenamento das informaes produzidas, quando em caso de interrupo, no considervel nem mesmo
quando envolve a serializao das informaes em disco. Em contrapartida, o overhead
122
Figura 6.5: Hotspots da Aplicao Modificada

total do tempo de execuo um fator que deve ser observado com cuidado. Como
visto, a aplicao, quando executada dentro do contexto de checkpoint, precisa realizar
(de maneira direta ou indireta) chamadas a diversos mtodos que no esto diretamente
relacionados ao negcio especfico da aplicao. De modo geral, correto considerar que
a execuo de aplicaes com o modelo de checkpoint aplicado em impressoras multifuncionais aceitvel.
123
CONCLUSO
Essa dissertao apresentou uma proposta para um mecanismo de checkpoint com

prevalncia de objetos, focada para recursos que, alm de possurem capacidades limitadas de memria e processamento, apresentam perodos de disponibilidade curtos, porm
freqentes. Um prottipo de soluo foi projetado, implementado e testado em um ambiente que simula as configuraes de hardware e software de uma impressora multifuncional. Esse prottipo foi, ento, projetado para ser adaptado dentro do worker da plataforma
XtremWeb, para oferecer uma soluo de checkpoint para essa plataforma.
Os resultados das avaliaes, realizadas atravs da simulao da execuo de aplicaes reais dentro desse modelo, permitiram constatar que a aplicabilidade da soluo
vivel. Com base nos resultados, foi possvel verificar que o modelo no adiciona
nenhum tipo de overhead considervel, seja em termos de memria, processamento ou
utilizao de disco, que exceda as expectativas. Dessa forma, correto assumir que a
utilizao do mecanismo de checkpoint proposto dentro de uma plataforma voluntria
como a XtremWeb, pode trazer benefcios em termos de armazenamento de resultados
produzidos.
No que diz respeito utilizao de memria, as avaliaes realizadas mostram que o
modelo de checkpoint com prevalncia de objetos faz uso de uma quantidade de memria que varia de acordo com a quantidade de tempo em que permanece desenvolvendo a
atividade voluntria. Isso significa que quanto mais tempo o recurso estiver processando
atividades voluntrias sem realizar operaes de snapshot, maior ser a quantidade de
memria alocada para o armazenamento temporrio das informaes. Dependendo da
quantidade de memria do recurso, esse espao alocado pode tornar-se um problema. Entretanto, como visto nessa dissertao, as impressoras multifuncionais modernas evoluem
a cada dia, apresentando recursos de hardware cada vez mais prximos dos desktops.
Dessa forma, o espao utilizado para esse armazenamento temporrio no chega a se
apresentar como um problema grave, embora seja um dos fatores crticos do modelo.
Em termos de utilizao em disco, o modelo de checkpoint proposto usa poucos recursos. Isso se deve ao fato de que a persistncia das informaes em disco fsico uma
abordagem complementar, ao mecanismo principal de persistncia em disco. O captulo
que mostrou a avaliao do modelo apresentou medies de utilizao de disco. Essas
medies mostraram que, conforme esperado, quanto maior a quantidade de informao
intermediria produzida, maior o tamanho fsico do arquivo produzido em disco. Entretanto, o crescimento dessa informao tido como aceitvel, dentro das configuraes
dos modelos de impressoras multifuncionais. Isso significa que a utilizao do disco fsico da impressora para armazenamento de informaes de snapshot no prejudicam nem
interferem na execuo e utilizao normal do recurso.
Por fim, uma das preocupaes consideradas desde o incio da pesquisa, era a de no
124
prejudicar a execuo normal do recurso. Isso significa que, ao utilizar o mecanismo de

checkpoint proposto em uma multifuncional, o tempo para reincio de uma impresso no
fosse prejudicado ao interromper o processamento voluntrio e armazenar as informaes
produzidas. Pela avaliao realizada, dentro de um ambiente muito semelhante ao real, a
retomada de execuo normal do recurso sofre um atraso que pode ser considerado como
aceitvel. Dessa forma, em termos de tempo para retorno ao processamento normal, o
modelo de checkpoint com prevalncia de objetos teve um resultado satisfatrio.
7.1
Reviso do Trabalho Desenvolvido
A dissertao de mestrado apresentada aqui foi divida em seis captulos que, juntos,
apresentaram desde as definies conceituais necessrias para o entendimento do modelo
de checkpoint proposto at o detalhamento de projeto e implementao do modelo propriamente dito. Inicialmente, no captulo 1 foi feita a introduo do trabalho, onde foram
apresentadas as vises gerais sobre os conceitos que envolvem o modelo de checkpoint
proposto. Nesse captulo, tambm foram apresentados os objetivos principais da pesquisa
e as contribuies obtidas a partir dos estudos realizados.
O captulo 2 apresentou uma viso geral sobre os diversos termos que envolvem o
conceito de computao distribuda, dando nfase especial ao modelo de computao
voluntria, que onde o trabalho proposto por essa dissertao se aplica. Nesse detalhamento, foram apresentados os principais conceitos relacionados com computao em
cluster, peer-to-peer e computao em grade.
Na seqencia, o captulo 3 apresentou as principais implementaes de mecanismos
para checkpoint e restart. Para isso, o estudo apresentou as implementaes disponveis nas plataformas de computao voluntria, implementaes em nvel de usurio e
sistema operacional, alm de abordagens de persistncia ortogonal. Esse estudo foi especialmente importante para que fosse possvel identificar as abordagens existentes, possibilitando projetar o mecanismo proposto e identificar aspectos que o diferenciam das
solues existentes.
O captulo 4 apresentou um estudo sobre o conceito de checkpoint em memria, com
os principais modelos e arquiteturas. Esse conceito de diskless checkpoint est diretamente relacionado com o modelo proposto, pois este faz uso da memria como mecanismo principal para persistncia das informaes intermedirias produzidas.
Finalmente, os captulos 5 e 6 apresentaram o projeto, implementao e validao do
modelo proposto. No captulo 5, o modelo foi apresentado e todos os componentes da
soluo foram detalhados. Juntamente com esse detalhamento, a proposta para mecanismo de checkpoint foi projetada para ser adaptada plataforma de computao voluntria XtremWeb, onde as modificaes necessrias para o worker dessa plataforma foram
mostradas. O captulo 6, na seqencia, utilizou o modelo implementado para validar a
sua utilizao dentro de um ambiente de execuo que simula uma impressora multifuncional. Nessa captulo, foram apresentadas de maneira detalhada as modificaes e
adaptaes que foram necessrias para que a aplicao fosse corretamente executada dentro do modelo checkpoint proposto. Nesse mesmo captulo, os resultados referentes
utilizao de memria, espao em disco e outras avaliaes, obtidas a partir da execuo
de uma aplicao real, foram apresentados e analisados.
125
7.2
Contribuies
O objetivo deste trabalho foi apresentar uma proposta de mecanismo de checkpoint

para plataformas de computao voluntria, atravs da prevalncia de objetos. Essa proposta direcionada para recursos com capacidades limitadas de processamento e memria, que apresentam perodos curtos, porm freqentes, de disponibilidade para projetos
voluntrios. Nesse contexto, a primeira contribuio foi a de possibilitar que esse tipo de
recurso, tipicamente descartado por ambientes de computao voluntria, possam ser utilizados e passem a produzir resultados vlidos e teis, agregando valor ao processamento
total do ambiente voluntrio.
Outra contribuio foi a de apresentar um mecanismo de checkpoint que inova ao utilizar o conceito de prevalncia de objetos para a persistncia dos resultados intermedirios. Conforme apresentado ao longo dessa dissertao, o modelo de checkpoint proposto
utiliza o conceito de prevalncia de objetos em memria, combinado com o processo peridico de checkpoint em disco para armazenamento dos resultados produzidos ao longo
do processamento voluntrio.
Alm disso, interessante incluir como contribuio, a utilizao de conceitos relacionados a diskless checkpoint combinados com a disk checkpoint para armazenamento dos
resultados. Essa abordagem hbrida se mostra como um fator diferencial no modelo de
checkpoint pois combina as vantagens do checkpoint tradicional em disco com a rapidez
das operaes realizadas em memria.
Como objeto final do estudo, o projeto para adaptao do worker do XtremWeb permite que seja possvel utilizar um mecanismo de checkpoint nessa plataforma que, por padro, no possui esse tipo de mecanismo. Com essa contribuio, a plataforma XtremWeb
poderia usufruir dos benefcios de armazenamento dos resultados intermedirios produzidos de maneira transparente e eficiente.
Para que as medies de disponibilidade de processamento voluntrio das impressoras
multifuncionais fossem possveis, foi desenvolvido um aplicativo que realiza verificaes
peridicas para obter o status do recurso em questo. A implementao dessa ferramenta
que realizou as medies de disponibilidade, tambm pode ser considerada como uma
contribuio prtica obtida a partir da pesquisa realizada atravs dessa dissertao.
Ao longo do desenvolvimento dessa pesquisa alguns artigos e resumos foram escritos
e submetidos a eventos regionais, nacionais e internacionais. Nessas publicaes, foram
relacionadas algumas contribuies e resultados obtidos durante a realizao do trabalho.
Para eventos internacionais, um artigo foi submetido para o XV Congreso Argentino de
Ciencias de la Computacion (Jujuy, Argentina). Em eventos nacionais, um artigo foi
submetido e publicado nos anais do III EPAC - Encontro Paranaense de Computao
(Paran, Brasil). Alm disso, um resumo foi submetido ao ERAD 2010.
7.3
Trabalhos Futuros
Os trabalhos futuros prevem a continuidade do desenvolvimento e utilizao do modelo de checkpoint proposto, no sentido de habilitar a utilizao de recursos com capacidades limitadas de hardware em ambientes de computao voluntria. O desenvolvimento desse mecanismo de checkpoint pode ser considerado como o primeiro passo de
um conjunto de atividades que podem viabilizar a participao desse tipo de recurso.
Dessa forma, abrem-se possibilidades para diversos trabalhos futuros, tanto dentro do
contexto do mecanismo de checkpoint proposto aqui, quanto da avaliao e utilizao
126
do mesmo dentro de plataformas voluntrias. A primeira idia para trabalho futuro est
na implantao do modelo de checkpoint proposto na plataforma XtremWeb, de acordo
com o projeto realizado aqui nessa dissertao. Trata-se de uma atividade prtica, mas
que oferece vantagens interessantes no s ao modelo proposto aqui, mas principalmente
plataforma voluntria, que passa a ter uma opo para armazenamento dos resultados
intermedirios produzidos.
Um aspecto que tambm poderia ser observado a quantidade de checkpoints realizados pelo recurso. Com o projeto atual, no existem limites de utilizao para o modelo, isto , no existe um nmero mximo de operaes de checkpoint que podem ser
realizadas. Entretanto, de interesse do projeto voluntrio como um todo realizar o processamento das atividades no menor tempo possvel. Com base nessa premissa, torna-se
interessante discutir at que ponto vantagem permanecer realizando o processamento
em curtos intervalos de tempo, armazenando a informao produzida ou repassar a atividade para outro recurso do ambiente voluntrio. A partir dessa anlise, pode ser feita a
utilizao de um mecanismo para escalonar as atividades entre os nodos, como proposto
por outros trabalhos dentro do nosso grupo de pesquisa.
Dentro da soluo e projeto atual, identificam-se alguns ajustes que podem ser teis
e certamente ofereceriam melhorias ao projeto. O primeiro aspecto seria o de descartar
o armazenamento de snapshots antigos. No modelo atual, todos os snapshots realizados
so mantidos em disco, ocasionando uma utilizao crescente e desnecessria, sob o ponto
de vista de recuperao posterior das informaes produzidas. Nesse sentido, descartar
snapshots antigos trariam o benefcio de utilizar menos espao em disco do recurso, j
que este possui configuraes limitadas.
Nessa mesma linha, interessante ampliar o escopo de aplicaes que podem ser
transformadas e adaptadas para o modelo de checkpoint apresentado aqui. O primeiro
passo para que essa ampliao seja possvel, permitir que o modelo de checkpoint seja
capaz de lidar com aplicaes que fazem uso de parmetros para sua invocao. O projeto
atual j est preparado para tal suporte, restando apenas alguns pequenos ajustes necessrios.
Como visto ao longo da dissertao, especialmente no captulo que trata diretamente
sobre o modelo proposto, para que a utilizao do mecanismo de checkpoint seja possvel, algumas alteraes so necessrias na aplicao-alvo. Nesse contexto, imprescindvel que todas as regras definidas sejam observadas, caso contrrio, o modelo de
checkpoint no ter xito na tarefa de armazenar os resultados intermedirios produzidos. Dessa forma, uma sugesto para trabalho futuro o projeto e implementao de um
pr-compilador que teria como principal funcionalidade verificar se as regras em questo
esto presentes na aplicao adaptada. Com a existncia desse compilador especfico,
seria possvel garantir, com segurana, que a aplicao em questo ser corretamente utilizada dentro do contexto de prevalncia, permitindo a realizao de checkpoints.
127
REFERNCIAS
AGBARIA, A.; FRIEDMAN, R. Starfish: fault-tolerant dynamic mpi programs on clusters of workstations. In: IEEE INTERNATIONAL SYMPOSIUM ON HIGH PERFORMANCE DISTRIBUTED COMPUTING, 8., Washington, DC, USA. Proceedings. . .
IEEE Computer Society, 1999. p.31.
AHMAD, I. Cluster Computing: a glance at recent events. IEEE Concurrency, Los Alamitos, CA, USA, v.8, n.1, p.6769, 2000.
AMIRI, K. et al. Dynamic Function Placement in Active Storage Clusters. [S.l.]: Carnegie
Mellon University, 1999.
ANDERSON, D. P. Boinc: a system for public-resource computing and storage. In:
IEEE-ACM INTERNATIONAL WORKSHOP ON GRID COMPUTING, 5. Anais. . .
[S.l.: s.n.], 2004. p.410.
ANDERSON, D. P. et al. SETI@home: an experiment in public-resource computing.
Commun. ACM, [S.l.], v.45, n.11, p.5661, November 2002.
ANDERSON, D. P. et al. Designing a runtime system for volunteer computing. In:
ACM/IEEE CONFERENCE ON SUPERCOMPUTING, 2006., New York, NY, USA.
Proceedings. . . ACM, 2006. p.126.
ASHOK, N. W. Grid in action: harvesting and reusing idle compute cycles. 2007.
ATKINSON, M. et al. An Orthogonally Persistent JavaTM. ACM SIGMOD Record,
[S.l.], v.25, p.110, 1996.
ATKINSON, M.; MORRISON, R. Orthogonally persistent object systems. The VLDB
Journal, Secaucus, NJ, USA, v.4, n.3, p.319402, 1995.
ATKINSON, M. P. et al. An approach to persistent programming. Readings in objectoriented database systems, San Francisco, CA, USA, p.141146, 1990.
BAKER, M. et al. Non-volatile memory for fast, reliable file systems. Conference on
Architectural Support for Programming Languages and Operating Systems (ASPLOS),
[S.l.], 1992.
BAKER, M. et al. Cluster Computing: a high-performance contender. Computer, [S.l.],
v.32, p.7980, 1999.
BARAK, A. et al. Scalable Cluster Computing with MOSIX for LINUX. In: IN PROCEEDINGS OF LINUX EXPO 99. Anais. . . [S.l.: s.n.], 1999. p.95100.
128
BARKAI, D. An Introduction to Peer-to-Peer Computing. Microcomputer Research Lab

Intel Corporation.
BOWMANM, I. Diskless Checkpointing Presentation. 2006.
BROWN, A. L. Persistent Object Stores. [S.l.]: Software Engineering Journal, 1988.
BRYANT, R.; HARTNER, B. Java, Threads, and Scheduling in Linux. 2009.
CAPPELLO, F. et al. Computing on Large Scale Distributed Systems: xtremweb architecture, programming models, security, tests and convergence with grid. FGCS Future
Generation Computer Science, [S.l.], v.21, n.3, p.417437, March 2005.
CAROTHERS, C.; SZYMANSKI, B. Checkpointing Multithreaded Programs. Dr. Dobbs
Journal, [S.l.], 2002.
CHANDRASEKARAN, S.; KEHOE, B. Technical Comparison of Oracle9i Real Application Clusters vs. IBM DB2 UDB EEE v8.1. [S.l.]: Oracle White Paper, 2002.
CHEN, P. M. et al. RAID: high-performance, reliable secondary storage. ACM Computing Surveys, [S.l.], 1994.
CHEN, P. M. et al. The Rio file cache: surviving operating system crashes. In: ASPLOSVII: PROCEEDINGS OF THE SEVENTH INTERNATIONAL CONFERENCE ON
ARCHITECTURAL SUPPORT FOR PROGRAMMING LANGUAGES AND OPERATING SYSTEMS, New York, NY, USA. Anais. . . ACM, 1996. p.7483.
CHIUEH, T.; DENG, P. Efficient checkpoint mechanisms for massively parallel machines. International Symposium on Fault-Tolerant Computing (FTCS), [S.l.], 1996.
CHIUEH, T.; DENG, P. Evaluation of Checkpoint mechanisms for massively parallel
machines. Proceeding of 26th Fault-Tolerance Computer Symposium, [S.l.], p.370379,
1996.
CIRNE, W. et al. Running Bag-of-Tasks Applications on Computational Grids: the mygrid approach. In: ICPP. Anais. . . [S.l.: s.n.], 2003. p.407.
CORPORATION, V. Db4o: native java e .net open source object database. 2009.
CROGRID. CRO-GRID Infrastructure:
http://www.srce.hr/.
questions and answers. Disponivel em
CRONK, D. et al. Metacomputing: an evaluation of emerging systems. 2000.

DEARLE, A. et al. Orthogonal Persistence Revisited. 2009.
DEVICES, U. Gridmp: hpc systems management for the complete distributed computing
lifecycle. Disponvel em http://www.univaud.com.
DIETER, W. R. et al. User-Level Checkpointing for Linux Threads Programs. In: FREENIX TRACK. 2001 USENIX ANNUAL TECHNICAL CONFERENCE, Berkeley, CA,
USA. Proceedings. . . USENIX Association, 2001. p.8192.
DOHERTY, M. Database Cluster for e-Science. UK e-Science All Hands Meeting, [S.l.],
2003.
129
DONGARRA, J. J. et al. Disaster Survival Guide in Petascale Computing: an algorithmic

approach. 2008.
ECONOMIST. A grid by any other name. Disponivel em http://public.euegee.org/files/EconomistDec04.pdf.
ELNOZAHY, E. et al. The performance of consistent checkpoint. 11th Symposium on
Reliable Distributed System, [S.l.], p.3947, 1992.
FEDAK, G. et al. XtremWeb: a generic global computing system. In Proceedings of the
IEEE International Symposium on Cluster Computing and the Grid (CCGRID01), [S.l.],
v.582-587, 2001.
FELDMAN, S. I.; BROWN, C. B. IGOR: a system for program debugging via reversible
execution. ACM SIGPLAN, Workshop on Parallel and Distributed Debugging, New York,
NY, USA, v.24, n.1, p.112123, 1989.
FIELDS, S. Hunting for wasted computing power: new software for computing networks
puts idle pcs to work. 2008.
FOSTER, I.; KESSELMAN, C. Globus: a metacomputing infrastructure toolkit. International Journal of Supercomputer Applications, [S.l.], v.11, p.115128, 1996.
FOSTER, I.; KESSELMAN, C. Globus: a metacomputing intrastructure toolkit. International Journal of Supercomputer Applications, [S.l.], v.22, p.115128, 1997.
FOSTER, I. T. What is the Grid? A Three Point Checklist. GRIDtoday, [S.l.], 2002.
FOSTER, I. T. et al. The Anatomy of the Grid: enabling scalable virtual organization.
International J. Supercomputer Applications, [S.l.], v.15, num 3, 2001.
FOSTER, M. Pursuing the APs to Checkpointing with UCLiK. In: INTERNATIONAL
LINUX SYSTEM TECHNOLOGY CONFERENCE, 10., Washington, DC, USA. Proceedings. . . IEEE Computer Society, 2003. p.147.
GALLAGER, R. G. Information Theory and Reliable Communication. [S.l.]: John Wiley
and Sons, 1968.
GARCIA-MOLINA, H.; SALEM, K. Main memory database systems: an overview. IEEE
Transactions on Knowledge and Data Engineering, [S.l.], v.4, 1992.
GIBSON, D. Checkpoint/restart for Solaris and Linux. 2009.
GIBSON, G. A. Redundant Disk Arrays: reliable, parallel secondary storage. MIT Press,
[S.l.], 1992.
GRIMSHAW, A. S. et al. The Legion vision of a worldwide virtual computer. Commun.
ACM, New York, NY, USA, v.40, n.1, p.3945, 1997.
HARGROVE, P. H.; DUELL, J. C. Berkeley lab checkpoint/restart (blcr) for linux clusters. In: PROCEEDINGS OF SCIDAC. 2006. Anais. . . Online]. Available:
http://stacks.iop.org/17426596/46/494, 2006. p.2006.
HENDRIKS, E. VMADump. 2009.
130
HEWLETT-PACKARD. Hewlett-Packard - Computers, Laptops, Servers and Printers.

2009.
HIGAKI, H. et al. Checkpoint and Rollback in Asynchronous Distributed Systems. In:
INFOCOM 97: PROCEEDINGS OF THE INFOCOM 97. SIXTEENTH ANNUAL
JOINT CONFERENCE OF THE IEEE COMPUTER AND COMMUNICATIONS SOCIETIES. DRIVING THE INFORMATION REVOLUTION, Washington, DC, USA.
Anais. . . IEEE Computer Society, 1997. p.998.
HUNG, E. Fault Tolerance and Checkpointing Schemes for Cluster of Workstations.
ELEC6062 Scalable Parallel Computing, [S.l.], 1998.
INC, X. Splash G640 Color Server for Xerox DocuColor 12 Series. 2009.
INRIA. XtremWeb: the open source platform for desktop grids. Disponivel em
http://www.xtremweb.net/.
JAMES S. PLANK YOUNGBAE KIM, J. D. Fault-tolerant matrix operations for
networks of workstations using diskless checkpointing. Parallel Distributed Computing,
[S.l.], v.43, p.125138, 1997.
JATIT. Journal of Theoretical and Applied Information Technology. Disponivel em
http://www.jatit.org/.
JOSEPH, A. D. et al. Mobile Computing with the Rover Toolkit. IEEE Transactions on
Computers, Los Alamitos, CA, USA, v.46, n.3, p.337352, 1997.
KASBEKAR, M. et al. Selective Checkpointing and Rollbacks in Multithreaded Objectoriented Environment. In: IEEE TRANSACTIONS ON RELIABILITY. Anais. . .
[S.l.: s.n.], 1999. p.325337.
KAWAGUCHI, A. et al. A flash-memory based file system. In: TCON95: PROCEEDINGS OF THE USENIX 1995 TECHNICAL CONFERENCE PROCEEDINGS ON
USENIX 1995 TECHNICAL CONFERENCE PROCEEDINGS, Berkeley, CA, USA.
Anais. . . USENIX Association, 1995. p.1313.
KESSELMAN, C. et al. A resource management architecture for metacomputing systems.
Proceedings of 12th International Parallel Processing Symposium e 9th Symposium on
Parallel and Distributed Processing Workshop on Job Scheduling Strategies for Parallel
Processing, [S.l.], 1998.
KULKARNI, D. et al. LINQ to SQL: .net language-integrated query for relational data.
2009.
LAADAN, O. et al. Transparent Checkpoint-Restart of Distributed Applications on Commodity Clusters. Proceedings of IEEE International Conference on Cluster Computing,
[S.l.], 2005.
LEXMARK. Lexmark Products. 2009.
LIO, W. Trustworthy service selection and composition reducing the entropy of serviceoriented web. 2005.
131
LU, C.-D. Scalable Diskless Checkpointing for Large Parallel Systems. 2005. Dissertao
(Mestrado em Cincia da Computao) University of Illinois at Urbana-Champaign.
LON, J. et al. Fail-Safe PVM: a portable package for distributed programming with
transparent recovery. [S.l.]: Carnegie Mellon University, 1993.
MEYER, N. User and Kernel Level Checkpointing. Proceedings of the Sun Microsystems
HPC Consortium Meeting, [S.l.], p.1523, 2003.
MICROSYSTEMS, S. Java Persistence API. 2009.
MILOJICIC, D. S. et al. Peer-to-Peer Computing. HP Laboratories Palo Alto.
MOSS, J. E. B.; HOSKING, A. L. Approaches to Adding Persistence to Java. 1996.
NERI, V. et al. Xtremweb: a generic global computing system. 1st IEEE International
Symposium on Cluster Computing and the Grid, [S.l.], p.582587, 2001.
NETBEANS. NetBeans Profiler. 2009.
OCONNOR, M. Process Migration on Chorus. 2009.
ORGANICK, E. The MULTICS system: an examination of its structure. [S.l.]: MIT
Press, 1972.
OSMAN, S. et al. The Design and Implementation of Zap: a system for migrating computing environments. In: IN PROCEEDINGS OF THE FIFTH SYMPOSIUM ON OPERATING SYSTEMS DESIGN AND IMPLEMENTATION (OSDI 2002. Anais. . . [S.l.: s.n.],
2002. p.361376.
OVEREINDER, B. et al. A dynamic load balancing system for parallel cluster computing.
Future Gener. Comput. Syst., Amsterdam, The Netherlands, The Netherlands, v.12, n.1,
p.101115, 1996.
PAN, D.; LINTON, M. Supporting Reverse Execution of Parallel Programs. ACM Sigplan
Notices, Workshop on Parallel and Distributed Debugging, [S.l.], v.24, p.124129, 1989.
P.ANDERSON, D.; FEDAK, G. The Computational and Storage Potential of Volunteer
Computing. In: CCGRID 06: PROCEEDINGS OF THE SIXTH IEEE INTERNATIONAL SYMPOSIUM ON CLUSTER COMPUTING AND THE GRID, Washington, DC,
USA. Anais. . . IEEE Computer Society, 2006. p.7380.
PARRINGTON, G. D. et al. The Design and Implementation of Arjuna. 1995.
PATTERSON, D. et al. A case for Redundant Array of Inexpensive Disks (RAID). ACM
SIGMOD Conference of Management of Data, [S.l.], p.109116, 1988.
PENG, L.; KIAN, L. N1GE6 Checkpointing and Berkeley Lab Checkpoint/Restart. 2009.
PINHEIRO, E. Truly-Transparent Checkpointing of Parallel Applications. 1998.
PLANK, J. et al. Diskless Checkpointing. IEEE Transactions Parallel and Distributed
System, [S.l.], v.9, p.972986, 1998.
132
PLANK, J.; LI, K. Faster checkpointing with N+1 parity. International Symposium on
Fault-Tolerant Computing (FTCS), [S.l.], 1994.
PLANK, J. S. A tutorial on Reed-Solomon coding for fault-tolerance in RAID-like systems. Software Practice and Experience, [S.l.], v.27, p.9951012, 1997.
PLANK, J. S. et al. Libckpt:transparent checkpointing under unix. Usenix Winter Technical Conference, [S.l.], p.213223, 1995.
PLANK, J. S. et al. Diskless Checkpointing. [S.l.]: University of Tenesse, 1998.
PLANK, J. S.; LI, K. Faster checkpointing with n+1 parity. FTCS, [S.l.], v.288297, 1994.
PRESS, H. Folding@home and genome@home: using distributed computing to tackle
previously intractable problems in computational biology. 2003.
PROCESS, J. C. Java Data Objects (JDO) Specification. 2009.
PRUITT, P. N. An Asynchronous Checkpoint and Rollback Facility for Distributed Computations. 2002. Tese (Doutorado em Cincia da Computao) College of William and
Mary.
RECHERCHE NUCLAIRE, O. E. pour la. Grid Cafe @ CERN. 2009.
REED, I.; SOLOMON, G. Polynomial Codes Over Certain Finite Fields. SIAM Journal
of Applied Math, [S.l.], v.8, p.300304, 1960.
RFC. The RFC Archive. 2009.
ROMAN, E. A Survey of Checkpoint/Restart Implementations. [S.l.]: Berkeley Lab,
2002.
SANCHO, J. C. et al. Current Practice and a Direction Forward in Checkpoint/Restart
Implementations for Fault Tolerance. In: IPDPS 05: PROCEEDINGS OF THE 19TH
IEEE INTERNATIONAL PARALLEL AND DISTRIBUTED PROCESSING SYMPOSIUM (IPDPS05) - WORKSHOP 18, Washington, DC, USA. Anais. . . IEEE Computer
Society, 2005. p.300.2.
SARMENTA, L. F. G. Volunteer Computing. 2001. Tese (Doutorado em Cincia da Computao) Department of Electrical Engineering and Computer Science. Massachusetts
Institute of Technology.
SHRIVASTAVA, S. K. et al. An Overview of the Arjuna Distributed Programming System. IEEE Softw., Los Alamitos, CA, USA, v.8, n.1, p.6673, 1991.
SILVA, L. M.; SILVA, J. An experimental study about diskless checkpointing. 24th Euromicro Conference Proceeding., [S.l.], v.1, p.395402, 1998.
SILVA, L. M.; SILVA, J. G. The Performance of Coordinated and Independent Checkpointing. In: IPPS 99/SPDP 99: PROCEEDINGS OF THE 13TH INTERNATIONAL
SYMPOSIUM ON PARALLEL PROCESSING AND THE 10TH SYMPOSIUM ON PARALLEL AND DISTRIBUTED PROCESSING, Washington, DC, USA. Anais. . . IEEE
Computer Society, 1999. p.280284.
133
SILVA, L.; SILVA, J. G. An Experimental Study about Diskless Checkpointing. In: EUROMICRO 98: PROCEEDINGS OF THE 24TH CONFERENCE ON EUROMICRO,
Washington, DC, USA. Anais. . . IEEE Computer Society, 1998. p.10395.
SILVA, M. M. et al. Checkpointing SPMD applications on Transputer networks. Scalable
High-Performance Computing Conference (SHPCC), [S.l.], 1994.
SKLAR, B. Digital Communications: fundamentals and applications. [S.l.]: PrenticeHall, 1988.
STAFF, B. BOINC Preferences. 2008.
STEEN, A. van der. Supercomputer and Cluster Computing. [S.l.]: Faculty of Science
Physics and Astronomy, Utrecht University, 2007.
STELLNER, G. CoCheck: checkpointing and process migration for mpi. In: IPPS 96:
PROCEEDINGS OF THE 10TH INTERNATIONAL PARALLEL PROCESSING SYMPOSIUM, Washington, DC, USA. Anais. . . IEEE Computer Society, 1996. p.526531.
STERLING, T. et al. BEOWULF: a parallel workstation for scientific computation. Proceedings of the 24th International Conference on Parallel Processing, [S.l.], p.1114, 1995.
STONE, N. et al. A Checkpoint and Recovery System for the Pittsburgh Supercomputing
Center Terascale Computing System. Pittsburgh Supercomputing Center, Pittsburgh.
SUDAKOV, O. et al. CHPOX: transparent checkpointing system for linux clusters. In:
IPDPS 05: PROCEEDINGS OF THE 14TH IEEE WORKSHOP ON INTELLIGENT
DATA ACQUISITION AND ADVANCED COMPUTING SYSTEMS: TECHNOLOGY
AND APPLICATIONS (IDAACS07), Dortmund. Anais. . . IEEE Computer Society,
2007. p.159164.
SUNDERAM, V. S. et al. Numerically stable real-number codes based on random matrices. Proceedings of the Computational Science - ICCS 2005, 5th International Conference, [S.l.], p.115122, 2004.
TAKAHASHI, T. et al. PM2: a high performance communication middleware for heterogeneous network environments. In: SUPERCOMPUTING 00: PROCEEDINGS OF
THE 2000 ACM/IEEE CONFERENCE ON SUPERCOMPUTING (CDROM), Washington, DC, USA. Anais. . . IEEE Computer Society, 2000. p.16.
TANENBAUM, A. S. Modern Operating Systems. [S.l.]: Prentice Hall Press, 2007.
TEAM, C. Condor Version 7.2.4 Manual. 2009.
TELECOM, D. SNMP Tutorial. 2009.
THAIN, D. et al. Distributed computing in practice: the condor experience: research
articles. Concurr. Comput. : Pract. Exper., Chichester, UK, v.17, n.2-4, p.323356, 2005.
TOTH, D. M. Improving the Productivity of Volunteer Computing. Worcester Polytechnic
Institute, [S.l.], 2004.
VILLELA, C. An introduction to object prevalence. 2002.
134
WANG, A.-I. et al. Conquest: better performance through a disk/persistent-ram hybrid

file system. In: ATEC 02: PROCEEDINGS OF THE GENERAL TRACK OF THE ANNUAL CONFERENCE ON USENIX ANNUAL TECHNICAL CONFERENCE, Berkeley, CA, USA. Anais. . . USENIX Association, 2002. p.1528.
WANG, Y.-M. et al. Checkpointing and Its Applications. In: FTCS 95: PROCEEDINGS
OF THE TWENTY-FIFTH INTERNATIONAL SYMPOSIUM ON FAULT-TOLERANT
COMPUTING, Washington, DC, USA. Anais. . . IEEE Computer Society, 1995. p.22.
WILSON, P.; MOHER, T. Demonic memory for process histories. SIGPLAN, Conference on Programming Language Design and Implementation, New York, NY, USA, v.24,
n.7, p.330343, 1989.
WU, M.; ZWAENEPOEL, W. eNVy: a non-volatile, main memory storage system. Conference on Architectural Support for Programming Languages and Operating Systems
(ASPLOS), New York, NY, USA, v.28, n.5, p.8697, 1994.
WUESTEFELD, K. Prevayler, a prevalence layer for Java. http://www.prevayler.org.
YAMAMOTO, H. et al. Multi-Class Composite N-gram language model for spoken language processing using multiple word clusters. In: ACL 01: PROCEEDINGS OF THE
39TH ANNUAL MEETING ON ASSOCIATION FOR COMPUTATIONAL LINGUISTICS, Morristown, NJ, USA. Anais. . . Association for Computational Linguistics, 2001.
p.531538.
ZHENG, G. et al. FTC-Charm++: an in-memory checkpoint-based fault tolerant runtime
for charm++ and mpi. IEEE International Conference on Cluster Computing, [S.l.], 2004.
ZHONG, H.; NIEH, J. CRAK: linux checkpoint / restart as a kernel module. [S.l.]: Department of Computer Science. Columbia University, 2002.

0007663521

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

0007663521

Uploaded by

Copyright:

Available Formats

UNIVERSIDADE FEDERAL DO RIO GRANDE DO SUL

RAFAEL DAL ZOTTO

Proposta de Mecanismo de Checkpoint com

Dissertao apresentada como requisito parcial

Prof. Dr. Cludio Fernando Resin Geyer

Porto Alegre, Setembro de 2010

CIP CATALOGAO NA PUBLICAO

UNIVERSIDADE FEDERAL DO RIO GRANDE DO SUL

LISTA DE ABREVIATURAS E SIGLAS . . . . . . . . . . . . . . . . . . . .

IMPLEMENTAES DE MECANISMOS PARA CHECKPOINT E RESTART . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

6 APLICAO DO MODELO E DESEMPENHO

LISTA DE ABREVIATURAS E SIGLAS

Application Programming Interface

BOINC Berkeley Infrastructure for Network Computing

Berkeley Lab Checkpoint/Restart

Common Intermediate Language

CORBA Common Object Request Broker Architecture

Common Language Runtime

Central Processing Unit

General Public License

Hypertext Transfer Protocol

Java Native Interface

Java Virtual Machine

Java Runtime Environment

Local Area Network

Multi Function Product/ Printer/ Peripheral

Message Passing Interface

Microsoft Intermediate Language

MTBF Mean Time Between Failures

Network Address Translation

Personal Digital Assistant

Parallel Virtual Machine

Piecewise Deterministic Assumption

Redundant Array of Inexpensive Disk

Random Access Memory

Remote Method Invocation

Remote Procedure Call

Silicon Graphics, Inc.

SNMP Simple Network Management Protocol

Secure Sockets Layer

Transmission Control Protocol

Terascale Computing System

eXtensible Markup Language

Classificao das implementaes de mecanismos de checkpoint/restart 34

Estrutura de Diskless Checkpoint para grandes sistemas . . . . . . .

Fluxo de utilizao diria de uma MFP . . . . . . . . . . . . . .

rvore de Chamadas do checkpoint Peridico . . .

Computao voluntria um tipo de computao distribuda na qual o proprietrio do

A Proposal for a Checkpoint Mechanism based on Memory Execution-Context

Volunteer computing is a type of distributed computing in which resource owners

Keywords: Volunteer computing, checkpoint, high-performance, object prevalence.

o, toda e qualquer informao produzida perdida, gerando um desperdcio de poder

Envolvido nesse contexto, o objetivo principal dessa pesquisa consiste em propor um

avaliado dentro de um contexto de execuo que simula as configuraes de hardware e

modificada e executada dentro do modelo de checkpoint proposto e comparado com a

devem ser suficientemente eficientes para remover ou mitigar gargalos de performance.

Cluster com Balanceamento de Carga

Cluster de Alto Desempenho

O objetivo desse tipo de arquitetura de cluster dividir a tarefa computacional em

Cluster com Web-Service

Cluster em Bases de Dados

Peer to Peer Computing

O termo peer-to-peer se refere a uma classe de sistemas e aplicaes que empregam

chamadas e das respostas e a maneira como so executadas, so de domnio especfico da