Documenti di Didattica
Documenti di Professioni
Documenti di Cultura
INSTITUTO DE INFORMTICA
PROGRAMA DE PS-GRADUAO EM COMPUTAO
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 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
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
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
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
API
Bag-of-Tasks
BLCR
CIL
CPU
GC
Global Computing
GPL
HTTP
HPC
High-Performance Computing
IP
Internet Protocol
JNI
JVM
JRE
LAN
LINQ
Language-Integrated Query
MFP
MHz
Megahertz
MPI
MSIL
NVRAMNon-Volatile RAM
PDA
P2P
Peer-to-Peer
PC
Personal Computer
PID
Process Identifier
PVM
PWD
RAID
RAM
RMI
RPC
SGI
Symmetric Multi-Processing
SSL
TCP
TCS
UDP
User-defined protocol
XML
XOR
Disjuno Exclusiva
XW
XtremWeb
LISTA DE FIGURAS
Figura 3.1:
Figura 3.2:
Figura 3.3:
Figura 4.1:
Figura 4.2:
Figura 4.3:
Figura 4.4:
Figura 4.5:
Figura 4.6:
Figura 4.7:
Figura 4.8:
.
.
.
.
.
.
.
.
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:
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
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:
.
.
.
.
.
.
.
.
.
.
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
Palavras-chave: Computao voluntria, Mecanismos para Checkpoint, Alto Desempenho, Prevalncia de Objetos.
ABSTRACT
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
1.1
Objetivos e Contribuio
17
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
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
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
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
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
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
23
24
2.3
Computao em Grade
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
27
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
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
GIMPS
Einstein@Home
Projeto, construdo na plataforma BOINC, que objetiva fracionar as ondas gravitacionais em pequenas pores e compar-las individualmente, contra modelos pr-definidos.
Nro. Ativo de usurios: 38,000
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.
Nro. Ativo de usurios: 14,000
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
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
Xgrid@Stanford
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.
Nro. Ativo de usurios: 31.000
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
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
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
31
32
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
33
34
3.2
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
35
36
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
37
3.3
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 ) ;
3.3.3
Libtckpt
40
Score
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
Esky
43
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
3.4
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
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
EPCKPT
46
3.4.3
CRAK
47
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
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
PS-Algol
Napier88
52
Arjuna
Persistent Java
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
54
3.6
Outras Implementaes
55
3.7
Consideraes Finais
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
57
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
4.2
Neighbor-Based Checkpointing
Mirroring
60
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
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
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
Forked Checkpoiting
Encoding Checkpointing
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
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
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
4.4
Checksum-Based Checkpointing
FAN-IN pode ser definido como o nmero de entradas padro de uma determinada entrada lgica.
66
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
k
Cm
(n + 1)k
k
Cm(n+1)
4.4.3
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
68
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
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:
= Ci1
..
.
Pn
ai1 jt Pjt
= 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
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
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
71
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
72
MODELO PROPOSTO
5.1
Origem da Proposta
73
5.1.1.1
Hardware
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
75
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
5.2
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
78
5.3
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
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
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
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
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 ) ;
}
}
}
83
5.5
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
85
Listagem de Cdigo
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
Listagem de Cdigo
87
p a c k a g e Checkpoint . TargetExtension ;
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
p a c k a g e Checkpoint . TargetExtension ;
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
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
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.
29
30
91
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
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
}
}
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
Listagem de Cdigo
p a c k a g e Checkpoint . TargetExtension ;
import
import
import
import
import
import
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 ) ;
}
c a t c h ( IOException io ) {
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
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
p a c k a g e Checkpoint . TargetExtension ;
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 ( ) ;
}
c a t c h ( IOException io ) {
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
Listagem de Cdigo
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 ;
}
}
98
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
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
101
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
Worker
103
Implementao
Arquitetura
104
Server
105
Arquitetura
106
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
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
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
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 }
Adaptando ThreadLaunch
110
5.8
Consideraes Finais
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
6.1
Aplicao-alvo
Cdigo Original
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 ( ) ) ;
System . exit ( 1 ) ;
}
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() ) ;
}
line = in . readLine ( ) ;
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.
import
import
import
import
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
;
System . exit ( 1 ) ;
}
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 ) ;
}
line = in . readLine ( ) ;
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
6.3
Cenrios de Testes
116
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
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.
6.4.2
118
Realizao de Snapshots
Criao de um snapshot
119
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
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
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
6.5
Consideraes Finais
122
123
CONCLUSO
124
7.1
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
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
129
130
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