Guiacluster PDF

Ministrio do Planejamento, Oramento e Gesto
SLTI Secretaria de Logstica e Tecnologia da Informao

DSI Departamento de Integrao de Sistemas de Informao
Guia de Estruturao e
Administrao do Ambiente de
Cluster e Grid
1.0
Braslia DF
Presidente da Repblica
Luiz Incio Lula da Silva
Vice-Presidente da Repblica
Jos de Alencar Gomes da Silva
Ministro de Estado do Planejamento, Oramento e Gesto

Paulo Bernardo Silva
Ministro de Estado da Casa Civil

Comit Executivo de Governo Eletrnico
Dilma Roussef
Secretrio de Logstica e Tecnologia da Informao

Secretrio Executivo de Governo Eletrnico
Rogrio Santanna dos Santos
Guia de Estruturao e Administrao do Ambiente de Cluster e Grid.

Braslia, 2006.
454 p. : il.
Inclui Bibliografia.
1. Cluster e Grid. 2. Governo Eletrnico. 3. Tecnologias da

Informao e Comunicao. 4. Agregados Computacionais.
A menos que modifiquemos a nossa maneira de pensar, no seremos capazes de
resolver os problemas causados pela forma como nos acostumamos a ver o mundo".
Albert Einstein
Realizao:
G UIA DE C LUSTER
Coordenao
Secretaria de Logstica e Tecnologia da Informao - SLTI

Ministrio do Planejamento, Oramento e Gesto
Colaborao Tcnico-Administrativa
Claudete Bezerra da Silva

Diego Sacramento
Fernando Mazoni
Especialistas Convidados
Alice Brito
Adenauer Yamin
Augusto Ovelar
Csar A. F. De Rose
Daniel Darlen Corra Ribeiro
Elizeu Santos-Neto
Fernando Ike
Lucius Trindade Curado e Silva
Marco Sinhoreli
Mario Dantas
Philippe O. A. Navaux
Reinaldo J. Moreira
Rodrigo Neves Calheiros
Roberto Pires de Carvalho
Tiaraj Asmuz Diverio
Walfredo Cirne
Consultores Tcnicos
Alex Sandro Soares

Elias Otvio de Paula Mussi
Leonardo Rodrigues de Mello
VERSAO 1.0 PGINA V

G UIA DE C LUSTER
Consultor Responsvel
Coordenao do Projeto de Cluster e Grid
Corinto Meffe
Leonardo Rodrigues de Mello
Coordenao Executiva
Corinto Meffe
Jos Antnio Borba Soares
Leandro Corte
Coordenao Geral
Rogrio Santanna dos Santos
VERSAO 1.0 PGINA VI

G UIA DE C LUSTER
Participao da Sociedade
A complexidade das tecnologias tratadas neste Guia requer a participao freqente da

sociedade. Este dilogo auxilia no aperfeioamento do contedo tcnico, na insero de
dados e ferramentas relacionados com a temtica e na correo de possveis inconsistn-
cias tcnicas.
O intuito de contar com a participao de especialistas, desde a primeira verso do Guia,

surge em funo da grande quantidade de tecnologias envolvidas, do grau de complexi-
dade das mesmas e pela necessidade de atingir as solues mais estveis e utilizadas nas
organizaes.
No seria possvel manter as informaes atualizadas e inserir o que h de mais moderno

em Cluster e Grid sem a participao da Sociedade.
Para tanto alguns colaboradores que encaminharam contedo merecem destaque por
atenderem as caractersticas descritas acima, so eles:
Contribuies registradas
Adenauer Yamin
Augusto Ovelar
Daniel Darlen Corra Ribeiro
Elizeu Santos-Neto
Lucius Trindade Curado e Silva
Marco Sinhoreli
Roberto Pires de Carvalho
Walfredo Cirne
VERSAO 1.0 PGINA VII

G UIA DE C LUSTER
Histrico do Documento
Data Verso Autor Alterao

01/12/05 0.0 Elias Mussi Estruturao do Sumrio
01/02/06 0.1 Trabalhos provindos da Verso inicial de desenvolvi-
equipe interna da SLTI. mento de contedo.
10/02/06 0.1.5 Elias Mussi Proposta do Sistema de con-
sulta e contribuio on-line
para o Guia de Cluster
05/05/06 0.2 Contribuies do Prof. Ade- Sesses sobre Paralelismo e Sis-
nauer Yamin (PPAD), de Lu- tema de Imagem nica (SSI).
cius Curado (SSI). Mais traba-
lhos da equipe da SLTI
17/06/06 0.3 Elias Mussi Disponibilizao do Sistema
de Consulta e Colaborao
do Guia de Cluster no ende-
reo http://guialivre.
governoeletronico.
gov.br/guiaonline/
guiacluster/
14/08/06 0.3.5 Equipe SLTI Expanso do contedo do do-
cumento, principalmente na
parte III.
14/08/06 0.4 Contribuio de Walfredo Captulo Grid Computing.
Cirne e Elizeu Santos-Neto.
01/09/06 0.4.5 Equipe SLTI Expanso de contedo, princi-
palmente da Parte II.
04/10/06 0.5 Contribuio de Marco Si- Captulo sobre Virtualizao;
nhoreli e trabalhos da Equipe Expanso de contedo, princi-
SLTI palmente da Parte III
22/10/06 0.6 Contribuio de Roberto Pi- Sesso de Armazenamento
res de Carvalho e trabalhos Distribudo.
da Equipe SLTI
24/11/06 0.7 Equipe SLTI Expanso do contedo do do-
cumento e correes.
01/04/07 1.0 Equipe SLTI Expanso do contedo e corre-
es.
VERSAO 1.0 PGINA VIII

G UIA DE C LUSTER
Nota Tcnica da Comisso de Redao
Este Guia foi elaborado pela equipe da Gerncia de Inovaes Tecnolgicas (GIT),
do Departamento de Integrao de Sistemas de Informao (DSI), da Secretaria
de Logstica e Tecnologia da Informao (SLTI), do Ministrio do Planejamento,
Oramento e Gesto (MP).
As diretrizes que compem este documento tm como base as definies do Go-

verno Eletrnico Brasileiro e respaldo legal no Sistema de Administrao dos
Recursos de Informao e Informtica - SISP, institudo atravs do DECRETO
no 1.048, de 21 de janeiro de 1994.
As orientaes tcnicas so fundamentadas em pesquisadores brasileiros e nas

principais tecnologias pertinentes aos ambientes de Cluster e Grid.
A tecnologia de Cluster e Grid, embora recente, possui um amplo acervo de ar-

quiteturas, modelos, ferramentas, middlewares e aplicativos.
A equipe tcnica responsvel pela elaborao deste documento conta com a co-
laborao da Comunidade Acadmica e de Software Livre para suprir lacunas
originadas pela complexidade e pela abrangncia do contedo do Guia de Clus-
ter.
O lanamento desta verso final representa a consolidao dos trabalhos de in-

sero de contedo e a devoluo sociedade do resultado do trabalho at este
instante, o qual j conta com importantes colaboraes de membros da comuni-
dade acadmica brasileira.
Colaboraes para este documento podem ser feitas atravs do stio http://
guialivre.governoeletronico.gov.br/guiacluster/ e pelo e-mail:
<guialivre@planejamento.gov.br>.
VERSAO 1.0 PGINA IX

G UIA DE C LUSTER
Distribuio
Secretaria de Logstica e Tecnologia da Informao. Verso 0.5

Lanamentos Pblicos
Verso 0.5 Encontro Mineiro de Software Livre 2006.

O Encontro Mineiro de Software Livre 2006, realizado
na cidade de Ouro Preto - MG entre os dias 10-12 de
outubro de 2006 http://emsl.softwarelivre.org/.
Verso 0.5 ParGov - SBAC-PAD 2006.

The 18th International Symposium on Computer Ar-
chiteture and High Performance Computing", realizado na
cidade de Ouro Preto - MG entre os dias 17-20 de outubro
de 2006 http://www.sbc.org.br/sbac/2006/.
Verso 0.5 III Frum Goiano de Software Livre. Realizado na cidade

de Goiania - GO entre os dias 27-28 de outubro de 2006.
Verso 0.6 IV CONISLI - Congresso Internacional de Software Livre.

IV Congresso Internacional de Software Livre, realizado na
cidade de So Paulo - SP entre os dias 03-05 de novembro
de 2006 http://www.conisli.org.
Verso 0.6 III LatinoWare 2006 - III CONFERNCIA LATINOAMERI-

CANA DE SOFTWARE LIVRE. Realizado na cidade de Foz
do Iguau - PR entre os dias 16 e 17 de Novembro de 2006.
Verso 1.0 8 FISL - 8 Frum Internacional Software Livre. Realizado

na cidade de Porto Alegre - RS entre os dias 12 e 14 de abril
de 2007.
VERSAO 1.0 PGINA X

G UIA DE C LUSTER
Direitos Autorais
Governo Brasileiro a reproduo em parte ou totalmente autorizada desde

que a fonte seja reconhecida, de acordo com as orientaes da CC-GNU GPL1 .
Figura 1: Creative Commons
1
General Public License cujo contedo est disponibilizado no Apndice A.
VERSAO 1.0 PGINA XI

Sumrio
Sumrio xi
Lista de figuras xxiv
Lista de tabelas xxviii
1 Prefcio xxxi
1.1 Abreviaes e Terminologia . . . . . . . . . . . . . . . . . . . . . . . xxxi
1.2 Pblico . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxxii
1.3 Autores . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxxii
1.4 Agradecimentos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxxiii
I Diretrizes Gerais 1
2 Governo Eletrnico e Novas Concepes Tecnolgicas 2
2.1 A Informtica Pblica Brasileira . . . . . . . . . . . . . . . . . . . . . 2
2.1.1 A Sociedade da Informao e a Inovao Tecnolgica . . . . 5
VERSAO 1.0 PGINA XII

G UIA DE C LUSTER SUMRIO
2.2 Governo Eletrnico Brasileiro . . . . . . . . . . . . . . . . . . . . . . 8
2.2.1 Diretrizes do Governo Eletrnico Brasileiro . . . . . . . . . . 10
2.2.2 Padres de Interoperabilidade de Governo Eletrnico . . . . 11
2.2.3 As Diretrizes do Governo Eletrnico e o Software Livre . . . 14
2.2.4 A Arquitetura de Cluster e Grid e as Diretrizes do Governo

Eletrnico . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.3 As Novas Demandas Computacionais . . . . . . . . . . . . . . . . . 18
2.3.1 Computao sob Demanda . . . . . . . . . . . . . . . . . . . 25
2.3.2 Aproveitamento de Ciclos Ociosos . . . . . . . . . . . . . . . 26
2.4 Dois Paradigmas Computacionais . . . . . . . . . . . . . . . . . . . 27
2.4.1 Computao de Grande Porte . . . . . . . . . . . . . . . . . . 28
2.4.2 Computao Distribuda . . . . . . . . . . . . . . . . . . . . . 30
2.4.3 Comparao: Grande Porte e Distribuda . . . . . . . . . . . 30
2.4.4 As Geraes da Computao Distribuda . . . . . . . . . . . 33
II Aspectos Gerenciais 35
3 Introduo 36
3.1 Vantagens Tcnicas de Utilizao de Cluster e Grid . . . . . . . . . 39
3.2 Arquitetura para sistemas crticos online em N Camadas . . . . . . 40
3.2.1 Camada de Aplicao . . . . . . . . . . . . . . . . . . . . . . 41
VERSAO 1.0 PGINA XIII

3.2.2 Camada de Banco de Dados . . . . . . . . . . . . . . . . . . . 41
3.2.3 Camada de Armazenamento . . . . . . . . . . . . . . . . . . 41
3.2.4 Diagrama da arquitetura proposta . . . . . . . . . . . . . . . 42
3.2.5 Consideraes sobre a arquitetura . . . . . . . . . . . . . . . 43
3.3 Possibilidades de Aplicaes Prticas de Cluster e Grid . . . . . . . 43
3.3.1 Cenrio - Aplicaes WEB . . . . . . . . . . . . . . . . . . . . 46
3.3.2 Cenrio - Minerao de Dados . . . . . . . . . . . . . . . . . 48
3.3.3 Cenrio - Processamento de Alto Desempenho . . . . . . . . 50
3.3.4 Cenrio - Alta Disponibilidade . . . . . . . . . . . . . . . . . 52
3.3.5 Cenrio - Banco de Dados . . . . . . . . . . . . . . . . . . . . 54
4 Viso Geral 56
4.1 A sensibilizao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
4.2 Os Recursos Humanos Envolvidos . . . . . . . . . . . . . . . . . . . 57
4.2.1 Aperfeioamento dos Tcnicos . . . . . . . . . . . . . . . . . 57
4.2.2 Consultoria . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
4.3 O Projeto de Cluster . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
4.3.1 O que deve ser observado . . . . . . . . . . . . . . . . . . . . 59
5 Processamento Paralelo: Sua Difuso e Uso 69
5.1 Aspectos para a Adoo do Processamento Paralelo . . . . . . . . . 70
VERSAO 1.0 PGINA XIV

5.1.1 Barreiras ao Crescimento da Freqncia de Operao dos

Processadores . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
5.1.2 Largura de Banda no Acesso Memria . . . . . . . . . . . . 71
5.1.3 Paralelismo Intrnseco do Mundo Real . . . . . . . . . . . . . 72
5.1.4 A Relao Custo-Benefcio dos Processadores de ltima

Gerao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
5.1.5 Aplicaes Extremamente Complexas . . . . . . . . . . . . . 73
5.1.6 Suporte Tolerncia a Falhas . . . . . . . . . . . . . . . . . . 74
5.1.7 Crescimento Modular . . . . . . . . . . . . . . . . . . . . . . 74
5.1.8 Disponibilidade de Software Aplicativo . . . . . . . . . . . . 76
5.1.9 Relao entre a Teoria e a Tecnologia . . . . . . . . . . . . . . 77
III Aspectos Tcnicos 78
6 Conceitos Bsicos 79
6.1 Arquiteturas Computacionais . . . . . . . . . . . . . . . . . . . . . . 79
6.1.1 A Classificao de Flynn para Arquiteturas de Computadores 80
6.1.2 Multiprocessadores . . . . . . . . . . . . . . . . . . . . . . . . 86
6.1.3 Multicomputadores . . . . . . . . . . . . . . . . . . . . . . . 87
6.1.4 Multiprocessadores Simtricos (Symmetric Multiprocessors -

SMP) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
6.1.5 ccNUMA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
VERSAO 1.0 PGINA XV

6.1.6 Processadores Massivamente Paralelos - MPP . . . . . . . . 88
6.1.7 Sistemas Distribudos . . . . . . . . . . . . . . . . . . . . . . 89
6.1.8 Clusters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
6.1.9 Grids . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
6.2 Dependabilidade . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
6.2.1 Ameaas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
6.2.2 Meios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
6.2.3 Atributos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
6.3 Escalonamento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
6.4 Alta Disponibilidade . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
6.5 Balanceamento de Carga . . . . . . . . . . . . . . . . . . . . . . . . . 99
6.6 Redes de Comunicaes . . . . . . . . . . . . . . . . . . . . . . . . . 100
6.6.1 A Importncia da Rede de Comunicao . . . . . . . . . . . 100
6.6.2 Redes de Interconexo Utilizadas em Arquiteturas Paralelas 100
6.6.3 Topologias da Rede de Interconexo . . . . . . . . . . . . . . 103
6.6.4 Dispositivos de interconexo . . . . . . . . . . . . . . . . . . 106
6.7 Protocolos de Comunicao . . . . . . . . . . . . . . . . . . . . . . . 111
6.7.1 Frame Relay . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111
6.7.2 Asynchronous Transfer Mode . . . . . . . . . . . . . . . . . . . 111
VERSAO 1.0 PGINA XVI

6.7.3 FDDI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
6.7.4 Modelo OSI . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
6.7.5 Protocolo IP . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113
6.7.6 Transmission Control Protocol . . . . . . . . . . . . . . . . . . . 113
6.7.7 User Datagram Protocol . . . . . . . . . . . . . . . . . . . . . . 114
6.7.8 Real-time Transport Protocol . . . . . . . . . . . . . . . . . . . . 114
6.7.9 Virtual Router Redundancy Protocol . . . . . . . . . . . . . . . 114
7 Cluster de Armazenamento 117
7.1 Introduo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117
7.2 Block Devices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118
7.2.1 Arranjo Redundante de Discos - RAID . . . . . . . . . . . . 119
7.2.2 RAID via Hardware e via Software . . . . . . . . . . . . . . . 120
7.2.3 Distributed Replicated Block Device - DRBD . . . . . . . . . . . 121
7.2.4 Global Network Block Device - GNBD . . . . . . . . . . . . . . 125
7.2.5 Internet SCSI - iSCSI . . . . . . . . . . . . . . . . . . . . . . . 127
7.3 Sistemas de Arquivos Distribudos . . . . . . . . . . . . . . . . . . . 130
7.3.1 Conceitos Bsicos . . . . . . . . . . . . . . . . . . . . . . . . . 130
7.3.2 Servios Oferecidos pelos SADs . . . . . . . . . . . . . . . . 133
7.3.3 Algumas Caractersticas Desejadas em SADs . . . . . . . . . 137
VERSAO 1.0 PGINA XVII

7.3.4 Network File System - NFS . . . . . . . . . . . . . . . . . . . 146
7.3.5 Andrew File System - AFS . . . . . . . . . . . . . . . . . . . . 150
7.3.6 Constant Data Availability - CODA . . . . . . . . . . . . . . 154
7.3.7 Lustre . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 158
7.4 Sistemas de Arquivos Paralelos . . . . . . . . . . . . . . . . . . . . . 159
7.4.1 Parallel Virtual Filesystem Version 1 - PVFS . . . . . . . . . . . 159
7.4.2 Parallel Virtual Filesystem Version 2 - PVFS2 . . . . . . . . . . 163
8 Cluster de Aplicao 169
8.1 Linux Virtual Server - LVS . . . . . . . . . . . . . . . . . . . . . . . . . 170
8.1.1 Nomenclatura e abreviaes . . . . . . . . . . . . . . . . . . 171
8.1.2 Tipos de Cluster LVS . . . . . . . . . . . . . . . . . . . . . . . 172
8.1.3 Algoritmos de escalonamento . . . . . . . . . . . . . . . . . . 176
8.1.4 Casos de uso de LVS . . . . . . . . . . . . . . . . . . . . . . . 180
8.2 Cluster Tomcat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181
8.2.1 Balanceamento de carga . . . . . . . . . . . . . . . . . . . . . 184
8.2.2 Compartilhamento de sesses . . . . . . . . . . . . . . . . . . 187
8.3 Heartbeat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 188
8.4 Zope Cluster . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189
9 Cluster de Banco de Dados 194
VERSAO 1.0 PGINA XVIII

9.1 Banco de Dados Distribudos . . . . . . . . . . . . . . . . . . . . . . 199
9.2 Replicao de Banco de Dados . . . . . . . . . . . . . . . . . . . . . 199
9.3 PostgreSQL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 201
9.3.1 PGpool . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 201
9.3.2 PGcluster . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 204
9.3.3 Slony . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 207
9.4 Mysql . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 208
9.4.1 Replicao em MySQL . . . . . . . . . . . . . . . . . . . . . . 208
9.4.2 MySQL Cluster . . . . . . . . . . . . . . . . . . . . . . . . . . 211
9.5 Middlewares independentes de Banco de Dados . . . . . . . . . . . . 212
9.5.1 Middleware Sequoia . . . . . . . . . . . . . . . . . . . . . . . 212
9.5.2 ParGRES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 221
10 Alta Capacidade de Processamento - HPC 223
10.1 Beowulf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 223
10.2 Sistema de Imagem nica - SSI . . . . . . . . . . . . . . . . . . . . . 224
10.2.1 As Principais Caractersticas de um Cluster SSI . . . . . . . 225
10.2.2 Os Principais Benefcios de um Sistema SSI . . . . . . . . . . 227
10.2.3 Memria Distribuda Compartilhada - DSM . . . . . . . . . 228
10.2.4 OpenMosix . . . . . . . . . . . . . . . . . . . . . . . . . . . . 229
VERSAO 1.0 PGINA XIX

10.2.5 Kerrighed . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 232
11 Ferramentas de Programao Paralela 235
11.1 Troca de Mensagens (Message Passing) . . . . . . . . . . . . . . . . . 235
11.1.1 Parallel Virtual Machine - PVM . . . . . . . . . . . . . . . . . . 236
11.1.2 Message Passing Interface - MPI . . . . . . . . . . . . . . . . . 237
11.2 Relaes Entre o Hardware e o Software para Explorao do Parale-

lismo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 239
11.2.1 Relao entre Algoritmos e Arquiteturas Paralelas . . . . . . 240
11.2.2 Propriedades de um Modelo de Programao para o Pro-

cessamento Paralelo . . . . . . . . . . . . . . . . . . . . . . . 244
11.3 A Explorao do Paralelismo: Nveis de Abstrao e Modelos . . . 249
11.3.1 Modelos nos quais o Paralelismo Explorado de Forma To-

talmente Implcita . . . . . . . . . . . . . . . . . . . . . . . . 249
11.3.2 Modelos com Assinalamento do Paralelismo Explcito . . . 254
11.3.3 Modelos com Assinalamento e Decomposio do Parale-

lismo Explcitos . . . . . . . . . . . . . . . . . . . . . . . . . . 257
11.3.4 Modelos com Assinalamento, Decomposio e Mapea-

mento do Paralelismo Explcitos . . . . . . . . . . . . . . . . 259
11.3.5 Modelos com Assinalamento, Decomposio, Mapeamento

e Comunicao Explcitos . . . . . . . . . . . . . . . . . . . . 261
11.3.6 Modelos nos quais o Paralelismo Explorado de Forma To-

talmente Explcita . . . . . . . . . . . . . . . . . . . . . . . . . 262
VERSAO 1.0 PGINA XX

12 Escalonadores de Tarefas 264
12.1 OpenPBS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 265
12.2 TORQUE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 266
12.3 MAUI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 267
12.4 Crono . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 268
13 Grids Computacionais 269
13.1 Introduo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 269
13.2 Grids de Servios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 274
13.2.1 Acesso a Servios . . . . . . . . . . . . . . . . . . . . . . . . . 274
13.2.2 Descoberta de Servios . . . . . . . . . . . . . . . . . . . . . . 276
13.2.3 Autenticao e Autorizao . . . . . . . . . . . . . . . . . . . 280
13.2.4 Privacidade de Dados . . . . . . . . . . . . . . . . . . . . . . 281
13.2.5 Composio de Servio . . . . . . . . . . . . . . . . . . . . . 282
13.2.6 Disponibilizao de Servios . . . . . . . . . . . . . . . . . . 284
13.2.7 Padronizao . . . . . . . . . . . . . . . . . . . . . . . . . . . 290
13.3 Grids para Alto Desempenho . . . . . . . . . . . . . . . . . . . . . . 294
13.3.1 Plataformas para Processamento Paralelo . . . . . . . . . . . 294
13.3.2 Execuo Remota . . . . . . . . . . . . . . . . . . . . . . . . . 300
13.3.3 Escalonamento . . . . . . . . . . . . . . . . . . . . . . . . . . 300
VERSAO 1.0 PGINA XXI

13.3.4 Imagem do Sistema . . . . . . . . . . . . . . . . . . . . . . . . 313
13.3.5 Segurana . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 314
13.4 Estudos de Caso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 318
13.4.1 Globus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 318
13.4.2 MyGrid . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 327
13.4.3 OurGrid . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 331
13.4.4 Condor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 335
13.5 Integrao de clusters em grids . . . . . . . . . . . . . . . . . . . . . 337
13.5.1 Globus GRAM . . . . . . . . . . . . . . . . . . . . . . . . . . 339
13.5.2 Alocao transparente de recursos . . . . . . . . . . . . . . . 339
13.6 Tendncias em Grids Computacionais . . . . . . . . . . . . . . . . . 340
14 Virtualizao de recursos 342
14.1 Principais tipos de virtualizao . . . . . . . . . . . . . . . . . . . . 342
14.1.1 Virtualizao por software . . . . . . . . . . . . . . . . . . . . 343
14.1.2 Virtualizao nativa . . . . . . . . . . . . . . . . . . . . . . . 344
14.2 XEN - Xen virtual machine monitor . . . . . . . . . . . . . . . . . . . . 345
14.2.1 Comparao . . . . . . . . . . . . . . . . . . . . . . . . . . . . 346
14.2.2 Sistema Operacional nativo versus virtualizao com Xen . 347
14.2.3 Paravirtualizao no Xen . . . . . . . . . . . . . . . . . . . . 348
VERSAO 1.0 PGINA XXII

IV Apndices 350
A Licena CC-GNU GPL 351
B Marcas Registradas 361
C Lista de Abreviaturas 363
D Tecnologias 368
E Glossrio 371
F O Ambiente LabCluster 380
F.1 Histrico do LabCluster . . . . . . . . . . . . . . . . . . . . . . . . . 381
F.2 Misso do LabCluster . . . . . . . . . . . . . . . . . . . . . . . . . . . 383
F.3 Descrio do Ambiente LabCluster . . . . . . . . . . . . . . . . . . . 383
F.4 Infra-estrutura de Hardware . . . . . . . . . . . . . . . . . . . . . . . 384
F.5 Poltica de Utilizao do Ambiente LabCluster . . . . . . . . . . . . 384
G Outros Documentos Produzidos 386
Referncias Bibliogrficas 387
VERSAO 1.0 PGINA XXIII

Lista de Figuras
1 Creative Commons . . . . . . . . . . . . . . . . . . . . . . . . . . . . xi
2.1 Evoluo da carga de processamento e a utilizao da computao

de grande porte. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
2.2 Evoluo da carga de processamento e a utilizao da soluo de

processamento distribudo. . . . . . . . . . . . . . . . . . . . . . . . 31
3.1 Evoluo da utilizao de Arquiteturas de alto desempenho. Fonte

Top500.org . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
3.2 Evoluo da utilizao de S.O. Fonte Top500.org . . . . . . . . . . . 37
3.3 Evoluo da utilizao por segmento de mercado. Fonte Top500.org 38
3.4 Esquema do modelo de cluster proposto. . . . . . . . . . . . . . . . 42
3.5 Sistema de alta disponibilidade com dois servidores sendo aces-

sados por 4 clientes. Um dos servidores Primrio(ativo) e outro
Secundrio(passivo) . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
5.1 Relao Carga X Custo de investimento, para plataforma Baixa X

Alta . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
6.1 Blocos bsicos dos computadores seqenciais . . . . . . . . . . . . . 79
VERSAO 1.0 PGINA XXIV

G UIA DE C LUSTER LISTA DE FIGURAS
6.2 Arquitetura genrica de multiprocessador de memria . . . . . . . 81
6.3 Arquitetura genrica de multiprocessador de memria comparti-

lhada . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
6.4 Arquitetura genrica sncrona matricial . . . . . . . . . . . . . . . . 86
6.5 Alternativas para conectar o processador a rede de interconexo . . 102
6.6 Topologia em barramento . . . . . . . . . . . . . . . . . . . . . . . . 104
6.7 Topologia em malha . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
6.8 Topologia em hipercubo . . . . . . . . . . . . . . . . . . . . . . . . . 105
6.9 Topologia em rvore . . . . . . . . . . . . . . . . . . . . . . . . . . . 106
6.10 Esquema de funcionamento de um sistema VRRP . . . . . . . . . . 115
7.1 Viso do nvel conceitual de funcionamento do DRBD. . . . . . . . 123
7.2 Fluxo de intercomunicao entre as camadas dos dispositivos Li-

nux - repare que o DRBD no tem como notificar o mdulo do
sistema de arquivos - mas o oposto ocorre. . . . . . . . . . . . . . . 124
7.3 Exemplo de cenrio GNBD . . . . . . . . . . . . . . . . . . . . . . . 127
7.4 Exemplo de uma rvore de diretrios . . . . . . . . . . . . . . . . . 131
7.5 Estrutura de diretrios distribuda . . . . . . . . . . . . . . . . . . . 136
7.6 Volumes, VSGs e AVSGs . . . . . . . . . . . . . . . . . . . . . . . . . 155
7.7 Viso Geral do PVFS . . . . . . . . . . . . . . . . . . . . . . . . . . . 161
7.8 Clientes acessando o PVFS . . . . . . . . . . . . . . . . . . . . . . . . 162
7.9 Fluxo de dados pelo kernel . . . . . . . . . . . . . . . . . . . . . . . 162
VERSAO 1.0 PGINA XXV

8.1 Esquema geral de um Linux Virtual Server . . . . . . . . . . . . . . 171
8.2 LVS-NAT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173
8.3 LVS-DR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175
8.4 LVS-Tun . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176
8.5 Viso geral de um cluster Tomcat . . . . . . . . . . . . . . . . . . . . 183
8.6 Balanceamento de carga via DNS Round-Robin . . . . . . . . . . . . 185
8.7 Balanceamento de carga via Apache mod_jk . . . . . . . . . . . . . 186
8.8 DNS round-robin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 191
8.9 ZEO/ZODB + LVS+OCFS2 . . . . . . . . . . . . . . . . . . . . . . . 193
9.1 Arquitetura PG-pool . . . . . . . . . . . . . . . . . . . . . . . . . . . 204
9.2 Sistema de balanceamento de carga . . . . . . . . . . . . . . . . . . . 205
9.3 Sistema de alta disponibilidade . . . . . . . . . . . . . . . . . . . . . 206
9.4 Princpio do Sequoia . . . . . . . . . . . . . . . . . . . . . . . . . . . 215
9.5 Exemplo de RAIDb-0 . . . . . . . . . . . . . . . . . . . . . . . . . . . 217
9.6 Exemplo de RAIDb-1 . . . . . . . . . . . . . . . . . . . . . . . . . . . 218
9.7 Exemplo de RAIDb-2 . . . . . . . . . . . . . . . . . . . . . . . . . . . 219
9.8 Exemplo de RAIDb-1-0 . . . . . . . . . . . . . . . . . . . . . . . . . . 220
9.9 Exemplo de RAIDb-0-1 . . . . . . . . . . . . . . . . . . . . . . . . . . 220
11.1 Modelo Para Computao Paralela . . . . . . . . . . . . . . . . . . . 244
VERSAO 1.0 PGINA XXVI

11.2 Nmeros de Fibonacci em Programao Funcional . . . . . . . . . . 250
11.3 Fontes de Paralelismo na Programao em Lgica . . . . . . . . . . 253
13.1 Acesso transparente a servios e recursos . . . . . . . . . . . . . . . 270
13.2 Acessando um servio usando RMI . . . . . . . . . . . . . . . . . . . 275
13.3 Acessando um servio usando CORBA [14] . . . . . . . . . . . . . . . 276
13.4 Interao entre cliente e provedor (Web Services) [345] . . . . . . . 277
13.5 Ilustrao da arquitetura OurGrid [36] . . . . . . . . . . . . . . . . . 289
13.6 Relacionamento entre OGSA, OGSI e Globus [345] . . . . . . . . . . . 292
13.7 Arquitetura multiprocessada . . . . . . . . . . . . . . . . . . . . . . 296
13.8 Arquitetura de um MPP . . . . . . . . . . . . . . . . . . . . . . . . . 296
13.9 Arquitetura de uma N O W . . . . . . . . . . . . . . . . . . . . . . . . 297
13.10Arquitetura de um Grid Computacional . . . . . . . . . . . . . . . . 298
13.11Ilustrao de um cenrio composto de vrios escalonadores . . . . 302
13.12Jacobi executando em quatro processadores em um MPP . . . . . . 305
13.13Escalonamento feito pelo Jacobi AppLes . . . . . . . . . . . . . . . . 307
13.14Desempenho do WQR . . . . . . . . . . . . . . . . . . . . . . . . . . . 309
13.15Desperdcio de ciclos com a replicao . . . . . . . . . . . . . . . . . 310
13.16Sumrio do desempenho de Storage Affinity comparado com outras

heursticas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 311
VERSAO 1.0 PGINA XXVII

13.17Sumrio do desperdcio de recursos por Storage Affinity comparado

com outras heursticas . . . . . . . . . . . . . . . . . . . . . . . . . . 312
13.18Arquitetura do GRAM [133] . . . . . . . . . . . . . . . . . . . . . . . 321
13.19Delegao entre escalonadores de aplicao [133] . . . . . . . . . . . 322
13.20Exemplo do uso de escalonadores no Globus [133] . . . . . . . . . . 323
13.21Arquitetura do Globus [345] . . . . . . . . . . . . . . . . . . . . . . . 327
13.22Arquitetura do MyGrid . . . . . . . . . . . . . . . . . . . . . . . . . 329
13.23Condor protocol [85] . . . . . . . . . . . . . . . . . . . . . . . . . . . 336
13.24Utilizao de clusters em grids. . . . . . . . . . . . . . . . . . . . . . 338
A.1 Creative Commons . . . . . . . . . . . . . . . . . . . . . . . . . . . . 351
VERSAO 1.0 PGINA XXVIII

Lista de Tabelas
2.1 Diferenas entre computao de grande porte e distribuda . . . . 32
3.1 Tabela Cenrio 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
6.1 Formas bsicas de tolerncia falhas. Fonte DANTAS [136] . . . . 93
6.2 Nveis de Alta Disponibilidade . . . . . . . . . . . . . . . . . . . . . 99
8.1 Exemplos de Stios que utilizam LVS . . . . . . . . . . . . . . . . . . 181
11.1 Relao entre as caractersticas do hardware e do software paralelo . 241
13.1 Comparao entre as plataformas de execuo para aplicaes pa-

ralelas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 300
13.2 Grid Machine Interface . . . . . . . . . . . . . . . . . . . . . . . . . . 328
B.1 Tabela de Referncia de Marcas Registradas . . . . . . . . . . . . . . 362
C.1 Lista de Abreviaturas . . . . . . . . . . . . . . . . . . . . . . . . . . . 367
D.1 Tabela de referncias de tecnologias . . . . . . . . . . . . . . . . . . 370
VERSAO 1.0 PGINA XXIX

G UIA DE C LUSTER LISTA DE TABELAS
F.1 Tabela de Hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . . 384
VERSAO 1.0 PGINA XXX

Captulo 1
Prefcio
1.1 Abreviaes e Terminologia
Sempre que possvel, na primeira vez em que uma abreviao for usada, ser
includa tambm a verso por extenso. No Apndice E encontra-se um glossrio
de termos tcnicos utilizados.
O Termo cluster utilizado neste documento se referindo as diversas implementa-

es de compartilhamento de recursos computacionais. Tipicamente, um cluster
utiliza os recursos de dois ou mais dispositivos de computao1 em conjunto para
um propsito comum. Exemplos de cluster so: Cluster de Processamento de
Alto Desempenho ou HPC, Cluster de Balanceamento de Carga e Alta Disponibi-
lidade, Cluster de Banco de Dados e Cluster de Armazenamento. Um outro termo
comumente usado o de aglomerado de computadores, utilizado com frequncia
pela comunidade acadmica brasileira.
Muitas vezes estes ambientes clusterizados"so construdos a partir de compu-

tadores convencionais (estaes de trabalho), ou seja, vrios computadores co-
muns ligados em rede que se comunicam e trabalham como se fosse uma m-
quina de grande porte, com capacidade de suportar um ambiente de grande de-
manda computacional.
1
Estes dispositivos tambm podem funcionar separadamente
VERSAO 1.0 PGINA XXXI

G UIA DE C LUSTER 1.2 - P BLICO
O Grid Computacional (The Computational Grid), uma rede de execuo de apli-

caes paralelas em recursos geograficamente dispersos e pertencentes a mlti-
plas organizaes. A tecnologia de grids cria a oportunidade de oferecer servios
sob demanda. Assim,Grid onde se torna possvel prover sob demanda qualquer
servio computacional (no somente servios para computao de alto desempe-
nho).
Os termos Software de Fonte Aberta (Open Source Software) e Software Livre (Free
Software) tem seus defensores e suas diferenas conceituais e jurdicas. Neste tra-
balho, usaremos o termo Software Livre por se tratar de uma poltica estratgica
do governo e pela inteno de destacar as caractersticas que o diferenciam do
Software de Fonte Aberta, especialmente sua disponibilizao no modelo da Li-
cena Pblica Geral (GPL).
Os termos do Sistema Operacional, como nomes de arquivos, sero apresentados

desta forma: Nome de arquivo.
Cdigos de programas sero apresentados da forma: Cdigo.
1.2 Pblico
Este Documento dirigido aos gerentes e tcnicos de Tecnologia da Informao

(TI) de todo o Governo Federal Brasileiro, e pode ser utilizado nos outros pode-
res: Executivo, Legislativo e Judicirio; servindo tambm como referncia para
os governos estaduais e municipais que tenham interesse em conhecer e utilizar
tecnologias de cluster e grid.
1.3 Autores
Os autores deste documentos so principalmente membros da equipe da Gern-

cia de Inovaes Tecnolgicas (GIT), do Departamento de Integrao de Sistemas
(DSI), da Secretria de Logstica e Tecnologia da Informao (SLTI) do Ministrio
do Planejamento, Oramento e Gesto.
VERSAO 1.0 PGINA XXXII

G UIA DE C LUSTER 1.4 - A GRADECIMENTOS
Muitas contribuies de pessoas e instituies externas tambm foram includas

neste Guia e esto devidamente registradas na parte inicial deste documento.
1.4 Agradecimentos
Agradecemos a todos as pessoas que participaram da construo deste docu-

mento, em especial aquelas que nos enviaram contribuies. A grande maioria
dessas pessoas esto citadas na sesso Coordenao e Participao da Sociedade,
no incio deste documento.
A Coordenao Executiva agradece ao apoio do Secretrio de Logstica e Tecno-

logia da Informao, Rogrio Santanna dos Santos, pela condio de ser o grande
incentivador para a insero desta tecnologia na Administrao Pblica Federal
(APF); ao Diretor do Departamento de Integrao de Sistemas de Informao,
Leandro Crte e ao ex-diretor Jos Antnio Borba Soares pelo apoio permanente.
Agradecimentos especiais pelos materiais cedidos para o Guia, para os colabo-

radores: Adenauer Yamin, Daniel Darlen Corra Ribeiro, Elizeu Santos-Neto,
Lucius Trindade Curado e Silva, Marco Sinhoreli, Roberto Pires de Carvalho e
Walfredo Cirne.
VERSAO 1.0 PGINA XXXIII

Parte I
Diretrizes Gerais
VERSAO 1.0 PGINA 1

Captulo 2
Governo Eletrnico e Novas

Concepes Tecnolgicas
2.1 A Informtica Pblica Brasileira
As primeiras empresas de informtica pblica surgiram em 1964, inseridas num

cenrio onde o pas ainda buscava desenvolver a economia sustentada no setor
agrrio. Naquela poca, o termo corrente para designar o que hoje conhecemos
comumemente como informtica era processamento de dados" , termo que no
incorporava ainda os recursos de comunicao presentes no cenrio da chamada
informtica" atual. Ademais, as polticas de informao eram estritamente rela-
cionadas ao tema da segurana do Estado (Torres [134]).
Nos anos seguintes, em especial na dcada de 70, o Brasil experimentou taxas

de crescimento expressivas, apoiadas na forte presena do investimento estatal.
Ao final deste perodo o domnio da tecnologia foi apontado como um fator de-
terminante, dentre outros, para a superao do problema de gerao de dficits
persistentes, tornando o clima propcio para a intensificao dos investimentos
pblicos em informtica, ao lado de uma poltica protecionista indstria nacio-
nal(Torres [134]).
Um exemplo desta poltica protecionista foi a Poltica Nacional de Informtica

(PNI), Lei 7.232, aprovada em 29 de Outubro de 1984 pelo Congresso Nacional,
VERSAO 1.0 PGINA 2

G UIA DE C LUSTER 2.1 - A I NFORMTICA P BLICA B RASILEIRA
com prazo de vigncia previamente estabelecido em 8 anos. A Lei tinha como

objetivo estimular o desenvolvimento da indstria de informtica no Brasil, por
meio do estabelecimento de uma reserva de mercado para as empresas de capital
nacional.
Apesar da importncia neste perodo do domnio nacional da tecnologia, alme-

jando a utilizao de tecnologias consideradas na poca de ponta", o Estado Bra-
sileiro acabou por se tornar, de certa forma, um vido consumidor tecnolgico.
Um grande parque computacional heterogneo foi estruturado baseado no pa-
radigma da computao de grande porte, num momento em que as tecnologias
computacionais eram desenvolvidas por empresas multinacionais e, posterior-
mente internalizadas no governo, sem um estmulo de pesquisa s universidades
brasileiras, bem como ao mercado das empresas nacionais.
Neste paradigma computacional, a grande capacidade de processamento de tran-

saes simultneas e alta disponibilidade dos servios esto diretamente relacio-
nadas ao hardware especializado produzido por poucas empresas no mundo. Este
modelo amplamente adotado, consolidou a base do processo de automatizao e
estruturao de sistemas e implementao de servios, que hoje atinge todos os
segmentos do Setor Pblico.
A falta de padres abertos e o hardware especializado acabam por tornar o pro-

cesso de negociao do governo para a aquisio de novos equipamentos e ser-
vios uma atividade limitada e desproporcional. Com poucas empresas capazes
de produzir e/ou prestar os servios para o atendimento das demandas e algu-
mas vezes a ausncia de concorrncia de empresas na oferta de bens e servios ao
governo, desenvolveram-se diversas relaes de dependncia tecnolgica com os
fornecedores. Isto ocorre em funo das caractersticas deste paradigma compu-
tacional, onde as tecnologias de computao de grande porte possuem um ele-
vado custo total de propriedade, serem utilizados majoritariamente em grandes
projetos e sistemas do governo.
A informtica dentro do setor pblico brasileiro estruturou-se de maneira frag-

mentada e isolada, tendo criado, diversas ilhas tecnolgicas e sistemas sem pa-
dres transversais, o que dificulta e algumas vezes inviabiliza a integrao, sendo
esta realizada, parcialmente, atravs de pontes", como por exemplo SERPRO1
1
O Servio Federal de Processamento de Dados (SERPRO) a maior empresa pblica de pres-
tao de servios em tecnologia da informao do Brasil, maiores informaes em:
VERSAO 1.0 PGINA 3

G UIA DE C LUSTER 2.1 - A I NFORMTICA P BLICA B RASILEIRA
e DATAPREV 2 , responsveis pela interligao destas diversas ilhas tecnolgicas

heterogneas. Ademais, as iniciativas de governo eletrnico, a presso e a co-
brana da sociedade brasileira pela transparncia e otimizao do uso de recur-
sos pblicos, bem como, o combate corrupo e fraude so cada vez mais
influentes, aumentando a necessidade de integrao dos sistemas e o poder com-
putacional necessrio para realizar anlises complexas de imensas bases de dados
existentes no governo.
As aes de modernizao da mquina pblica desde o Plano Nacional de Des-

burocratizao3 at a Reforma Administrativa [175] , no foram capazes de atin-
gir os ambientes de tecnologia da informao e comunicao e os sistemas de
informao do governo. Isto ocorreu pela dissociao entre a reformulao dos
processos administrativos e o modelo de informatizao proposto.
Realizar estas mudanas e atender a necessria otimizao da mquina pblica,

de forma a melhor atender o cidado, dificultado ou inviabilizado no para-
digma da computao de grande porte, seja por conta dos recursos e investi-
mentos necessrios para se estabelecer esse processo, seja pela dificuldade para
se integrar sistemas, imposta pela falta de padres. Diante deste cenrio se faz
necessria a busca por alternativas computacionais inovadoras interoperveis,
plenamente auditveis, independentes de fornecedor, economicamente sustent-
veis para sistemas crticos governamentais e que fomentem o desenvolvimento e
pesquisa de novas tecnologias.
Buscando reverter este quadro de dependncia tecnolgica o governo brasileiro

tem investido, atravs do Ministrio da Cincia e Tecnologia e de parcerias en-
tre empresas pblicas e universidades, no desenvolvimento de tecnologias de
Cluster e Grid, baseadas em software livre e voltadas para aplicao de governo
eletrnico. Estas tecnologias de Cluster e Grid tm sido largamente utilizadas em
instituies de pesquisa e empresas privadas e estatais, alguns exemplos so: Pe-
http://www.serpro.gov.br/.
2
A Empresa de Processamento de Dados da Previdncia Social (Dataprev), ela a responsvel
pelo processamento da maior folha de pagamento do pas, alcanando mais de 20 milhes de
beneficirios/ms. Maiores informaes em: http://www.dataprev.gov.br.
3
O Programa Nacional de Desburocratizao da Secretaria de Gesto do Ministrio do Planeja-
mento, Oramento e Gesto, Decreto no 3335, de 11 de janeiro de 2000, que previa: Desburocrati-
zar a Administrao Pblica fundamental para preparar o pas aos novos desafios. imperativo
que o Estado se mostre gil e competente no atendimento de seus cidados, como tambm im-
prescindvel que esses no se intimidem ao procurar os servios pblicos e que tenham certeza
da boa qualidade e da eficincia do servio prestado".
VERSAO 1.0 PGINA 4

G UIA DE C LUSTER 2.1.1 - A S OCIEDADE DA I NFORMAO E A I NOVAO T ECNOLGICA
trobras, Sistema Nacional de Processamento de Alto Desempenho (SINAPAD),

Instituto de Pesquisas Espaciais (INPE), Laboratrio Nacional de Computao
Cientfica (LNCC), Google, HP, IBM, Sun, Itautec, Departamento de Defesa Ame-
ricano (DOD), National Center for Supercomputing Applications (NCSA), entre ou-
tros.
importante salientar que um fator decisivo para a adoo de tecnologias de

cluster e grid no governo brasileiro est relacionada possibilidade de reverter o
quadro de consumismo tecnolgico desenvolvido ao longo das ltimas 2 (duas)
dcadas e promover o domnio e independncia tecnolgica do Estado Brasileiro.
Existe uma mudana de paradigma entre as tecnologias de computao distri-

buda e de computao de grande porte. Na computao distribuda o impor-
tante no a capacidade de processamento"de um nico equipamento, mas sim
a capacidade de processamento coletiva" de um conjunto de equipamentos.
Nesta abordagem vrios equipamentos com pouca capacidade podem formar um
ambiente com grande capacidade de processamento e caso ocorra a falha de um
equipamento, o outro assumir a sua funo sem prejuzo para a execuo do
sistema. Desta forma, existe a reduo da necessidade de equipamentos com
hardware especfico, tolerante a falhas e com redundncia.
Atravz da utilizao de hardware padro x86 (pc) e sem a necessidade de redun-

dncias e dispositivos especiais no hardware possvel construir sistemas com
hardware de baixo custo, compatvel com padres abertos e internacionais, redu-
zindo a dependncia de fornecedores. Com o emprego de solues baseadas em
software livre possvel ainda eliminar a dependncia tecnolgica e estimular o
desenvolvimento de solues pelos centros de pesquisa, universidades, rgos
de governo e empresas privadas, devido as caractersticas de licenciamento do
software livre que permitem utilizar o software para qualquer fim, com liberdade
para distribuio, alterao e cpia.
2.1.1 A Sociedade da Informao e a Inovao Tecnolgica
Para a insero neste novo cenrio mundial da economia voltada informao e

tecnologia, cada pas desenvolveu estratgias que levou em considerao o seu
grau de desenvolvimento tecnolgico conjugado com as suas peculiaridades. No
VERSAO 1.0 PGINA 5

Brasil, o marco inicial desse processo foi a criao do programa Sociedade da

Informao, por meio do Decreto no 3.294, de 15 de dezembro de 1999, com o
objetivo de viabilizar a nova gerao da Internet e suas aplicaes em benefcio
da Sociedade Brasileira4 ", estruturado em sete linhas de ao:
Mercado, trabalho e oportunidades;
Universalizao de servios para a cidadania;
Educao na sociedade da informao;
Contedos e identidade cultural;
Governo ao alcance de todos;
P&D, tecnologias-chave e aplicaes;
Infra-estrutura avanada e novos servios.
Esse programa busca contribuir, de forma efetiva, para:
a construo de uma sociedade mais justa, em que sejam observados princ-

pios e metas relativos preservao de nossa identidade cultural, fundada
na riqueza da diversidade;
a sustentabilidade de um padro de desenvolvimento que respeite as dife-

renas e busque o equilbrio regional;
a efetiva participao social, sustentculo da democracia poltica.
Com tal esforo, em setembro de 2000, o Governo brasileiro produziu, dentre

outros documentos, o chamado Livro Verde"[135], que identificou o conjunto
das aes estabelecidas para impulsionar a Sociedade da Informao no Brasil,
contemplando ampliao do acesso Internet, meios de conectividade, formao
de recursos humanos, incentivo pesquisa e ao crescimento, comrcio eletrnico
e desenvolvimento de novas aplicaes (Guia Livre [151]).
4
O objetivo do Programa Sociedade da Informao integrar, coordenar e fomentar aes para a utili-
zao de tecnologias de informao e comunicao, de forma a contribuir para que a economia do pas tenha
condies de competir no mercado global e, ao mesmo tempo, contribuir para a incluso social de todos os
brasileiros na nova sociedade" disponvel em http://www.socinfo.org.br/sobre/programa.htm.
VERSAO 1.0 PGINA 6

A sociedade da informao no um modismo. Representa uma profunda mu-

dana na organizao da sociedade e da economia, havendo quem a considere
um novo paradigma tcnico-econmico. um fenmeno global, com elevado po-
tencial transformador das atividades sociais e econmicas, uma vez que a estru-
tura e a dinmica dessas atividades inevitavelmente sero, em alguma medida,
afetadas pela infra-estrutura de informaes disponvel. tambm acentuada
sua dimenso poltico-econmica, decorrente da contribuio da infra-estrutura
de informaes para que as regies sejam mais ou menos atraentes em relao
aos negcios e empreendimentos (Livro Verde [135]).
Na sociedade da informao, o cenrio econmico transforma-se de tal modo que

a inovao e a converso de conhecimento em vantagem competitiva passam a
constituir importantes diferenciais. Da rapidez na gerao e difuso de inova-
es, decorrem a drstica diminuio da vida til dos produtos e a necessidade
de modernizao contnua da produo e da comercializao de bens e servios.
Da converso do conhecimento surgem as possibilidades de se incorporar os be-
nefcios da tecnologia com maior agilidade.
Para a nova economia, no basta dispor de uma infra-estrutura moderna de

comunicao; preciso competncia para transformar informao em conheci-
mento. A educao um elemento-chave para a construo de uma sociedade da
informao e condio essencial para que pessoas e organizaes estejam aptas a
lidar com o novo, a criar e, assim, garantir seu espao de liberdade e autonomia.
O desafio, portanto, duplo: superar antigas deficincias e criar as competncias
requeridas pela nova economia.
O governo, nos nveis federal, estadual e municipal, tem o papel de assegurar o

acesso universal s tecnologias da informao e comunicao e a seus benefcios,
independentemente da localizao geogrfica e da situao social do cidado,
garantindo nveis bsicos de servios, estimulando a interoperabilidade de tec-
nologias e de redes. A sociedade civil deve zelar para que o interesse pblico
seja resguardado, buscando organizar-se para monitorar e influenciar, sistemati-
camente, os poderes pblicos e as organizaes privadas (Livro Verde [135]).
Assim desafios da sociedade da informao demandam cada vez mais uma

grande quantidade de recursos computacionais, devido a ampla difuso de ser-
vios e aplicaes ao pblico geral, em especial aos cidados. Neste contexto, o
Livro Verde" aponta uma srie de tecnologias consideradas chave para o desen-
VERSAO 1.0 PGINA 7

G UIA DE C LUSTER 2.2 - G OVERNO E LETRNICO B RASILEIRO
volvimento deste processo, dentre estas tecnologias encontra-se o Processamento

de Alto Desempenho, abordado no captulo 8, que ilustra os seguintes tipos de
aplicaes: Genoma humano, Disperso de poluio, Biologia estrutural, Previ-
so meteorolgica, Modelagens de Informao.
Esta tecnologia pode ainda ser largamente aplicada para aperfeioar a prpria
gesto do governo - coordenao, planejamento, execuo e controle de aes,
contabilidade pblica, etc. - e suas transaes comerciais com o setor privado. O
conjunto dessas demandas e das Diretrizes de Governo Eletrnico, de utilizao
da WEB para prestao da maior parte destes servios, estes que tm uma grande
demanda computacional, com grande quantidade de acesso, usurios simult-
neos e alta demanda de processamento, acabam trazendo tona as arquiteturas
de cluster e grid computacional. Existem outros exemplos do uso das tecnologias
de informao e comunicao pela mquina administrativa pblica, dentre eles:
a prestao de informaes ligadas aos servios pblicos, o acompanhamento das
aes de governo e conduo dos negcios pblicos (por ex. compras governa-
mentais), o acesso direto aos governantes e representantes eleitos.
O setor governamental o principal indutor de aes estratgicas rumo Soci-

edade da Informao. Primeiramente, porque cabe ao governo definir o quadro
regulatrio dentro do qual projetos e iniciativas concretas podero ser formula-
das. Segundo, porque como regra o governo o maior comprador/contratador
de bens e servios em tecnologias de informao e comunicao em um pas. As-
sim, uma deciso do governo em apoio a uma tecnologia ou servio pode abrir
algumas avenidas de atividades ao setor privado, bem como conduzir outras a
becos sem sada. Terceiro, porque o governo, com o uso exemplar de tecnologias
de informao e comunicao em suas atividades, pode acelerar grandemente
o uso dessas tecnologias em toda a economia, em funo da maior eficincia e
transparncia de suas prprias aes"(Livro Verde [135]).
2.2 Governo Eletrnico Brasileiro
O Governo Eletrnico foi concebido como instrumento de transformao da so-

ciedade brasileira, estabelecendo diretrizes e parmetros para a criao de uma
sociedade digital.
VERSAO 1.0 PGINA 8

G UIA DE C LUSTER 2.2 - G OVERNO E LETRNICO B RASILEIRO
Com o passar do tempo, a chamada Sociedade da Informao apresentou no-

vos paradigmas que mereciam igualmente a ateno do Governo Eletrnico.
Assim, em suas diretrizes, foram explicitados:
[...] O papel do Estado neste mundo em transformao continua funda-

mental como agente estratgico para o atendimento da demanda de maior
participao direta dos cidados e, ao mesmo tempo, a tomada de decises
centrais estratgicas e rpidas.
O crescimento das informaes em rede, o aumento da transparncia, e a

conseqente diminuio da burocracia estatal, aumentaro o controle social
sobre o Estado, o que contribuir para a democratizao do processo decis-
rio e para uma maior efetividade da ao governamental.
Neste ambiente de transformaes, o Governo Eletrnico pretende ser um

agente democrtico, estratgico, socialmente justo e ao mesmo tempo efici-
ente na prestao de servios aos seus cidados.(Vide stio do Governo Ele-
trnico [6]) "
Com a preocupao de melhor adequar o Pas a esse cenrio, foram criados, por
meio de decreto de 29 de outubro de 2003, comits tcnicos especficos no mbito
do Comit Executivo do Governo Eletrnico: Implementao de Software Livre,
Incluso Digital, Integrao de Sistemas, Sistemas Legados e Licenas de Soft-
ware, Gesto de Stios e Servios On-Line, Infra-Estrutura de Rede, Governo para
Governo (G2G), Gesto de Conhecimento e Informao Estratgica.
Segundo o stio do Governo Eletrnico[6], as principais linhas de ao do Poder

Executivo Federal em tecnologia da informao e comunicao esto estrutura-
das na direo a um governo eletrnico que procura promover: a universalizao
do acesso aos servios, a transparncia das suas aes, a integrao de redes e o
alto desempenho dos seus sistemas. Neste sentido o governo vem atuando em
trs frentes fundamentais: a interao com o cidado, a melhoria da sua prpria
gesto interna, e a integrao com parceiros e fornecedores. Neste processo
importante o compartilhamento de recursos do governo, a unicidade e troca de
informaes entre aplicaes, e a responsabilizao e credenciamento de gestores
da informao, que permita uma integrao das redes de governo, com indepen-
dncia, respeitando as peculiaridades setoriais dos rgos.
VERSAO 1.0 PGINA 9

G UIA DE C LUSTER 2.2.1 - D IRETRIZES DO G OVERNO E LETRNICO B RASILEIRO
2.2.1 Diretrizes do Governo Eletrnico Brasileiro
Em decorrncia do Decreto de 29 de outubro de 2003, a implementao do Go-

verno Eletrnico passou a ser realizada segundo sete princpios, que foram assim
concebidos5 :
[...] como referncia geral para estruturar as estratgias de interveno, ado-

tadas como orientaes para todas as aes de Governo Eletrnico, gesto do
conhecimento e gesto da TI no governo federal[6]:
1. A prioridade do Governo Eletrnico a promoo da cidadania.
2. A Incluso Digital indissocivel do Governo Eletrnico.
3. O Software Livre um recurso estratgico para a implementao do

Governo Eletrnico.
4. A gesto do conhecimento um instrumento estratgico de articulao

e gesto das polticas pblicas do Governo Eletrnico.
5. O Governo Eletrnico deve racionalizar o uso de recursos.
6. O Governo Eletrnico deve contar com um arcabouo integrado de po-

lticas, sistemas, padres e normas.
7. Integrao das aes de Governo Eletrnico com outros nveis de go-

verno e outros poderes.
Nesse novo contexto, a atuao do Governo Eletrnico pretende melhorar a pres-

tao de servios aos cidados, com aumento da transparncia e diminuio da
burocracia, contribuindo para a democratizao do processo decisrio, a efetivi-
dade das aes governamentais e a promoo da incluso digital.
Para dar suporte a toda demanda computacional que gerada por esses princ-
pios, que se prope a utilizao de arquiteturas computacionais baseadas em
Cluster e Grids no governo, como forma de criar um ambiente computacional
robusto, de alto grau de confiana e de baixo custo.
5
Oficinas de Planejamento Estratgico. RELATRIO CONSOLIDADO. Comit Executivo do Go-
verno Eletrnico. Maio de 2004. pg 8.
VERSAO 1.0 PGINA 10

G UIA DE C LUSTER 2.2.2 - PADRES DE I NTEROPERABILIDADE DE G OVERNO E LETRNICO
2.2.2 Padres de Interoperabilidade de Governo Eletrnico
Com a inteno de estruturar mecanismos capazes de promover a eficincia da

Administrao Pblica no contexto da Sociedade da Informao, articulada s
aes estabelecidas para implantao do Governo Eletrnico, o Governo brasi-
leiro elaborou um conjunto de premissas, polticas e especificaes tcnicas re-
gulamentadoras para utilizao da Tecnologia da Informao e da Comunicao,
denominada Arquitetura e-PING Padres de Interoperabilidade6 de Governo
Eletrnico".
A Arquitetura e-PING define um conjunto mnimo de premissas, polticas e

especificaes tcnicas, que regulamentam a utilizao da Tecnologia de Infor-
mao e Comunicao (TIC) no Governo Federal, estabelecendo as condies de
interao com os demais poderes e esferas de governo e com a sociedade em
geral. As reas cobertas pela e-PING, esto segmentadas em: Interconexo; Se-
gurana; Meios de Acesso; Organizao e Intercmbio de Informaes e reas de
Integrao para Governo Eletrnico.
Assim, pela e-PING,
A existncia de uma infra-estrutura de Tecnologia da Informao e Comu-

nicao (TIC) que se preste como o alicerce para a criao dos servios de go-
verno eletrnico o pr-requisito para o fornecimento de melhores servios
sociedade, a custos mais baixos. Um governo moderno e integrado exige
sistemas igualmente modernos e integrados, interoperveis, trabalhando de
forma ntegra, segura e coerente em todo o setor pblico.
Polticas e especificaes claramente definidas para interoperabilidade e ge-
renciamento de informaes so fundamentais para propiciar a conexo do
governo, tanto no mbito interno como no contato com a sociedade e, em
maior nvel de abrangncia, com o resto do mundo. A e-PING concebida
como uma estrutura bsica para a estratgia de governo eletrnico, e permite
racionalizar investimentos em TIC, por meio do compartilhamento, reutili-
zao e intercmbio de recursos tecnolgicos."
A e-PING apresenta, em cada um dos seus segmentos, polticas tcnicas norte-

6
Os conceitos de interoperabilidade adotados nesta arquitetura esto evidenciados no Docu-
mento de Referncia, disponvel em http://www.eping.e.gov.br.
VERSAO 1.0 PGINA 11

adoras para estabelecimento das especificaes de seus componentes, que so

fundamentadas em algumas polticas gerais. Para este trabalho, as principais
polticas gerais levantadas pela e-Ping, que atingem e/ou norteiam o desenvol-
vimento de sistemas de Cluster e Grid so (e-PING verso 1.9 [2] - pg: 9) :
Alinhamento com a INTERNET: todos os sistemas de informao da admi-

nistrao pblica devero estar alinhados com as principais especificaes
usadas na Internet e com a World Wide Web;
Adoo do XML como padro primrio de intercmbio de dados;
Desenvolvimento e adoo de um Padro de Metadados do Governo Ele-

trnico - e-PMG, baseado em padres internacionalmente aceitos;
Escalabilidade: as especificaes selecionadas devero ter a capacidade de

atender alteraes de demanda no sistema, tais como, mudanas em volu-
mes de dados, quantidade de transaes ou quantidade de usurios. Os
padres estabelecidos no podero ser fator restritivo, devendo ser capazes
de fundamentar o desenvolvimento de servios que atendam desde neces-
sidades mais localizadas, envolvendo pequenos volumes de transaes e de
usurios, at demandas de abrangncia nacional, com tratamento de grande
quantidade de informaes e envolvimento de um elevado contingente de
usurios;
Adoo Preferencial de Padres Abertos: a e-PING define que, sempre que

possvel, sero adotados padres abertos nas especificaes tcnicas. Pa-
dres proprietrios so aceitos, de forma transitria, mantendo-se as pers-
pectivas de substituio assim que houver condies de migrao. Sem pre-
juzo dessas metas, sero respeitadas as situaes em que haja necessidade
de considerao de requisitos de segurana e integridade de informaes.
Quando disponveis, solues em Software Livre so consideradas prefe-
renciais.
Em sua segunda parte, Especificao Tcnica dos Componentes da e-PING", v-

rios pontos so levantados de interesse para novos projetos de sistemas de infor-
mtica e informao. Principalmente no que se pode caracterizar como compu-
tao distribuda, com a utilizao de Web Services e de Arquitetura Orientada
Servios (SOA).
VERSAO 1.0 PGINA 12

Com a utilizao de Web Services para a interligao, integrao e interoperabili-

dade de sistemas. Da sesso 6.1. Interconexo: Polticas Tcnicas":
6.1.7. Sempre que possvel, deve ser utilizada tecnologia baseada

na web em aplicaes que utilizaram Emulao de Terminal anterior-
mente."
6.1.8. A tecnologia de Web Services recomendada como padro de
interoperabilidade da e- PING."
6.1.9. Os Web Services devero ser registrados e estar localizados em
estruturas de diretrio compatveis com o padro UDDI. O protocolo
de acesso a essa estrutura dever ser o HTTP."
6.1.10. O protocolo SOAP recomendado para comunicao entre os
clientes e os Web Services e a especificao do servio dever utilizar a
linguagem WSDL."
Na e-PING, Web Service"est definido como:
Os Web Services so aplicaes de software, identificadas por uma URI (Uni-

form Resource Identifier), cujas interfaces e ligaes so capazes de serem de-
finidas, descritas e descobertas por artefatos baseados em XML. Alm disso,
possuem suporte para integrao direta com outras aplicaes de software,
utilizando, como padro de interoperabilidade, mensagens escritas em XML
e encapsuladas em protocolos de aplicao padro da Internet.
A necessidade de integrao entre os diversos sistemas de informao de go-
verno, implementados em diferentes tecnologias, s vezes de forma simult-
nea e em tempo real, implica na adoo de um padro de interoperabilidade
que garanta escalabilidade e facilidade de uso.
A tecnologia de Web Services adequada para atender tais necessidades,
alm de ser independente em relao aos Sistemas Operacionais e s Lingua-
gens de Programao.
O uso de Web Services contempla tanto transferncias de documentos entre
Instituies, quanto solicitaes para execuo de servios remotos."
E em conjunto so recomendados as seguintes especificaes:
Protocolo de troca de informaes: SOAP v1.2, como definido pela W3C;
VERSAO 1.0 PGINA 13

G UIA DE C LUSTER 2.2.3 - A S D IRETRIZES DO G OVERNO E LETRNICO E O S OFTWARE L IVRE
Infra-estrutura de registro:Especificao UDDI v3.0.2 (Universal Description,

Discovery and Integration) definida pela OASIS;
Linguagem de definio do servio: WSDL 1.1 (Web Service Description Lan-

guage) como definido pelo W3C.
Um outro fator importante observado na sesso de Integrao para Governo

Eletrnico, onde se define as diretrizes tcnicas para o segmento, dela (a sesso
10.1 reas de Integrao para Governo Eletrnico: Polticas Tcnicas") se tem:.
A partir do entendimento de que a materializao do uso de XML Schemas

se d atravs de servios interoperveis:
Recomenda-se que a Arquitetura Orientada a Servios - SOA - e as pol-

ticas tcnicas relacionadas ao Segmento Interconexo sejam observadas
no projeto e implementao de aplicaes baseadas nos XML Schemas
referidos;
O segmento passa a referenciar a iniciativa Arquitetura Referencial de

Interoperao dos Sistemas Informatizados de Governo - AR", que um
modelo de Arquitetura Orientada a Servios, adaptado realidade dos
Sistemas Informatizados de Governo e que, oportunamente poder ser
acessada em http://guialivre.governoeletronico.gov.br/
ar/"
Assim, com essas polticas de padronizao, o governo cria mecanismos para que
os projetos em computao distribuda entre os rgos do Governo possam a ser
estruturados e obtenham maiores vantagens das arquiteturas de Cluster e Grid.
Essas padronizaes j so as bases para tecnologias existentes na rea, que hoje
so maduras e utilizadas pela indstria.
2.2.3 As Diretrizes do Governo Eletrnico e o Software Livre
As diretrizes do Programa Brasileiro de Governo Eletrnico demonstram que a

Gesto do Conhecimento e o uso de Padres Abertos e Software Livre so ins-
trumentos estratgicos de articulao e gesto de polticas pblicas porque possi-
bilitam a produo compartilhada e colaborativa de conhecimento, assegurando
VERSAO 1.0 PGINA 14

assim, a habilidade de criar, organizar e compartilhar solues e conhecimentos

estratgicos para o Estado Brasileiro.
O Guia Livre - Referncia de Migrao para Software Livre do governo federal",

documento norteador para a migrao e utilizao de Software Livre na APF,
explicita os benefcios obtidos pelo Estado ao se optar por este tipo de tecnologia.
Como por exemplo:
Nesse cenrio, a filosofia do Software Livre surge como oportunidade para

disseminao do conhecimento e nova modalidade de desenvolvimento tec-
nolgico, em funo do novo paradigma que se estabelece na relao de
quem produz o software (sejam empresas, sejam programadores autnomos)
com a tecnologia propriamente dita."
Assim, a adoo do Software Livre por parte do Estado amparada prin-

cipalmente pelos princpios de Impessoalidade, Eficincia e Razoabilidade7 ,
visando melhoria na qualidade dos servios prestados e promoo dos
desenvolvimentos tecnolgico e social.
Portanto, o Estado se beneficia diretamente com a adoo do Software Livre,

tanto no aspecto de sua estruturao para atendimento s demandas sociais,
como no seu papel de promover desenvolvimento. Desse modo, possibili-
tamos a integrao das polticas de modernizao administrativa, incluso
social baseadas na Tecnologia da Informao e no desenvolvimento indus-
trial.
A questo do Software Livre est contextualizada em amplo cenrio inte-

grado, composto por aes de desenvolvimento tecnolgico, insero ade-
quada do Pas na chamada Sociedade da Informao, promoo da cida-
dania, incluso digital e racionalizao de recursos. "
O Guia Livre"define como principais razes para o uso de Software Livre:
7
O artigo 37 da Constituio da Repblica apresenta os Princpios Basilares da Administra-
o Pblica: legalidade, impessoalidade, moralidade, publicidade e eficincia. O princpio da
razoabilidade possui fundamentao implcita, sendo evidenciado em algumas Constituies Es-
taduais.
VERSAO 1.0 PGINA 15

Necessidade de adoo de padres abertos para o Governo Eletrnico (e-

Gov);
Nvel de segurana proporcionado pelo Software Livre;
Eliminao de mudanas compulsrias que os modelos proprietrios im-

pem periodicamente a seus usurios, em face da descontinuidade de su-
porte a verses ou solues;
Independncia tecnolgica;
Desenvolvimento de conhecimento local;
Possibilidade de auditabilidade dos sistemas;
Independncia de fornecedor nico.
So apresentados os motivos pelos quais no basta ter acesso ao cdigo aberto,

mas preciso desenvolver comunidades capazes de contribuir para a evoluo
dos cdigos e algoritmos disponibilizados, criando inovaes, gerando melhorias
e aperfeioando os mesmos. As motivaes no podem ser apenas econmicas,
mas tambm devem ser orientadas pelas possibilidades de criao e de avanos
nas reas de produo, do conhecimento e de novas tecnologias, assim estimu-
lando o desenvolvimento de todo um conjunto de reas relacionadas ao software,
ao conhecimento e gesto do Estado Brasileiro.
O software livre, por princpio, depende do emprego de padres abertos. Tal uso
vem a facilitar tambm aes relacionadas com integrao de sistemas, otimiza-
o de processos, reutilizao de cdigos e adoo de arquiteturas computacio-
nais abertas.
O compartilhamento da informao e a adoo do software livre por muitos r-

gos pblicos e privados contribui para que o produto se mantenha atualizado
e ganhe um corpo muito superior ao que cada instituio isoladamente poderia
fazer e, sobretudo, se sustente no apenas por ser uma licena de software livre
adequada, mas tambm pela criao de uma comunidade que venha a zelar para
o seu desenvolvimento, compartilhando saberes e solues. A comunidade con-
tribui para manter o software vivo, corrigindo seus defeitos, aperfeioando seu
funcionamento, introduzindo inovaes e fazendo com que o produto se conso-
lide mais robusto e a cada dia se torne mais conhecido por um conjunto maior de
profissionais do setor e por diferentes segmentos da sociedade.
VERSAO 1.0 PGINA 16

G UIA DE C LUSTER 2.2.4 - A A RQUITETURA DE C LUSTER E G RID E AS D IRETRIZES DO G OVERNO E LETRNICO
A razo pela escolha preferencial do software livre no governo federal motivado

pelos resultados obtidos com o seu compartilhamento junto sociedade. O soft-
ware livre tambm possibilita ao cidado o direito de acesso aos servios pblicos
e ao conhecimento sem obrig-lo a usar uma plataforma especfica.
A utilizao de software livre em solues de Cluster e Grid" uma tendncia

clara que vem se estabelecendo nos ltimos anos:
De acordo com o top500.org8 , 72% dos computadores mais rpidos do mundo

so clusters, e o Linux j est presente em 73% destes.
Os principais desafios de utilizao de software livre no desenvolvimento de solu-

es em Cluster e Grid" para a construo de sistemas crticos governamentais
consistem na possibilidade de se aproveitar a grande quantidade de solues e
softwares disponveis para os ambientes de Cluster e Grid", bem como na pers-
pectiva de compartilhamento dos sistemas desenvolvidos com outros rgos e
instituies pblicas, dentro da perspectiva conceitual do software pblico (vide
[270]).
2.2.4 A Arquitetura de Cluster e Grid e as Diretrizes do Governo

Eletrnico
As principais razes pela escolha preferencial por arquiteturas de cluster e grid no

governo federal esto embasadas nas diretrizes de governo eletrnico de utiliza-
o de software livre e racionalizao de recursos e encontram-se descritas abaixo:
independncia tecnolgica;
independncia de fornecedor;
integrao de processos de inovao tecnolgica nas estruturas de infor-

mtica pblica, como instrumento de melhoria da qualidade de servios,
competividade e eficincia;
estmulo ao desenvolvimento de tecnologias nacionais e a Poltica Nacional

de Informtica;
8
http://www.top500.org/stats
VERSAO 1.0 PGINA 17

G UIA DE C LUSTER 2.3 - A S N OVAS D EMANDAS C OMPUTACIONAIS
adoo de padres abertos de hardware9 e software;
interoperabilidade como um fator preponderante no desenvolvimento de

sistemas e arquiteturas computacionais no governo;
aproveitamento dos potenciais disponibilizados pela ampla estrutura de re-

des computacionais do governo federal.
O presente documento apresenta as possibilidades, tecnologias e cenrios de uti-

lizao de cluster e grid no Governo Federal, tendo como objetivo ampliar seu
uso interno no governo de maneira a melhor atender as novas demandas compu-
tacionais da Sociedade da Informao que, segundo a diretriz de modernizao
da mquina pblica, encontram-se cada vez mais internalizadas no governo bra-
sileiro.
2.3 As Novas Demandas Computacionais
As atividades econmicas que utilizam redes eletrnicas como plataforma tec-

nolgica tm sido denominadas negcios eletrnicos (e-business). Essa expres-
so engloba os diversos tipos de transaes comerciais, administrativas e cont-
beis, que envolvem governo, empresas e consumidores. O comrcio eletrnico
(e-commerce) a principal atividade dessa nova categoria de negcios.
Os atores institucionais envolvidos nos servios governamentais so o prprio

Governo (G), Instituies Externas (B, de business), e o Cidado (C), que intera-
gem entre si de vrias maneiras. H cinco tipos de relaes entre esses atores em
aplicaes governamentais:
B2B (business-to-business):
transaes entre empresas, exemplos: EDI, portais verticais de negcios;
B2C/C2B (business-to-consumer/consumer-to-business):
transaes entre empresas e consumidores, exemplos: lojas e shoppings vir-
tuais;
9
Tambm conhecido como hardware commodity, trata-se de hardware padro de mercado
fornecido por diversas empresas que concorrem entre si para oferecer as melhores condies de
suporte, qualidade e preo para o governo
VERSAO 1.0 PGINA 18

B2G/G2B (business-to-government/government-to-business):
transaes envolvendo empresas e governo, exemplos: EDI, portais, com-
pras. Corresponde a aes do Governo que envolvem interao com entida-
des externas. O exemplo mais concreto deste tipo a conduo de compras,
contrataes, licitaes, etc, via meios eletrnicos;
C2C (consumer-to-consumer):
transaes entre consumidores finais (exemplos: sites de leiles, classifica-
dos on-line);
G2C/C2G (government-to-consumer/consumer-to-government):
transaes envolvendo governo e o cidado (consumidores finais dos servi-
os do Governo), exemplos: pagamento de impostos, servios de comuni-
cao). Corresponde a aes do Governo de prestao (ou recebimento) de
informaes e servios ao cidado via meios eletrnicos. O exemplo mais
comum deste tipo a veiculao de informaes em um website de um rgo
do governo, aberto a todos os interessados;
G2G (government-to-government):
transaes entre instituies do governo em qualquer nvel ou esfera do
Poder. Corresponde a funes que integram aes do Governo horizon-
talmente, exemplo: no nvel Federal, ou dentro do Executivo; ou vertical-
mente, exemplo: entre o Governo Federal e um Governo Estadual.
A informatizao de operaes internas e de servios prestados pelo Governo

remete necessidade de se planejar, implementar e operar grandes aplicaes
de tecnologias de informao e comunicao, envolvendo o desenvolvimento de
pacotes de software de grande complexidade, para execuo em plataformas usu-
almente bastante heterogneas de computadores e redes.
Tais aplicaes, especialmente as de escala nacional, que costumam tratar de

imensas quantidades de dados, que perpassaro inmeras geraes tecnolgicas,
so to carregadas de variveis e condicionantes que, tipicamente, so descritos
e caracterizados como sistemas complexos":
tm dimenses gigantescas, tais como milhes de usurios, centenas de fun-

es, etc.;
VERSAO 1.0 PGINA 19

tm especificao dinmica, isto , se modifica ao longo do tempo, para

acomodar novas necessidades, reviso de prioridades, etc.;
nunca terminam de ser implementados, como conseqncia natural das

duas caractersticas anteriores.
Assim os softwares desenvolvidos pela administrao pblica tm de optar pe-

las tecnologias adequadas e compatveis, seguindo as diretrizes de Governo Ele-
trnico e os padres de interoperabilidade j definidos pela e-PING. A adoo
de padres tcnicos e sua institucionalizao so fundamentais para assegurar
que aplicaes governamentais, mesmo resultando de uma mirade de iniciati-
vas descentralizadas e descoordenadas de desenvolvimento, possam interoperar
e se integrarem.
A idia de desenvolvimento em espiral de sistemas bastante antiga e est na

base da estrutura de se ter uma seqncia de verses para um servio. Muitas
vezes, as verses so impostas pela evoluo tecnolgica. Mas especialmente
no caso de software, o desenvolvimento em espiral utilizado como estratgia
defensiva para o projeto de sistemas complexos.
Aplicaes governamentais, mais do que quaisquer outras, demandam uma

abordagem em espiral. Contudo, com demasiada freqncia, elas so concebi-
das na forma de processos lineares com viso demasiadamente simplista, com
cronogramas irrealistas e sem um plano de evoluo de longo prazo.
Os desafios da Sociedade da Informao" apresentados no Livro Verde, a in-

sero do Brasil neste processo Global, a disseminao do acesso a Internet e as
pesquisas do meio acadmico, convergiram em novas possibilidades de aplica-
o da tecnologia da informao na disponibilizao de servios e informaes
aos cidados.
Existe uma percepo no governo e uma presso da sociedade em torno da me-

lhoria da qualidade dos servios prestados aos cidados, bem como para o au-
mento substancial da transparncia dos processos governamentais e o combate
fraude e corrupo. Para atender estas demandas se faz necessrio atingir um
nvel maior de integrao entre os sistemas governamentais e criar novos siste-
mas de inteligncia capazes de transformar o imenso volume de dados atual em
informao til e agregada, atravs da utilizao de sistemas de Business Inteli-
VERSAO 1.0 PGINA 20

gence (BI) e de Enterprise Resource Planning (ERP) [272].
Alm da iminente necessidade de integrao e atribuio de valor agregado aos

dados transformando-os em informao, importante salientar que a quantidade
de servios e portais agregadores destas informaes e de interao com os cida-
dos tambm dever crescer conjuntamente com a democratizao do acesso
Internet, e sua conseqente utilizao como meio de comunicao entre governo
e cidados, no contexto de desenvolvimento do Governo Eletrnico.
A ampliao e a melhoria da qualidade dos processos internos e dos servios

prestados pelo governo refletem-se na necessidade de aumento da capacidade
computacional do setor pblico e, por se tratarem de servios crticos, possuem
como caractersticas principais de demandas computacionais:
alta disponibilidade;
suporte a milhes de usurios simultneos;
alta capacidade de processamento;
capacidade de trabalhar com bancos de dados da ordem de milhes de re-

gistros;
tolerncia a falhas de hardware e software;
facilidade de integrao e interoperabilidade;
adoo de padres abertos de hardware e software;
armazenamento massivo da ordem de TeraBytes de dados;
A necessidade de ampliao da malha computacional, atendendo as caracters-

ticas expostas acima, deve superar um conjunto de restries ou problemas que
esto relacionados com a utilizao de computao de grande porte para o efetivo
atendimento das novas demandas, sendo eles:
Limitao financeira dos investimentos pblicos e a crescente necessidade

de racionalizao do uso de recursos pblicos em TI, que muitas vezes im-
possibilitam o desenvolvimento ou implementao de um novo sistema di-
ante do custo total de propriedade envolvido na aquisio de hardware e
software para computao de grande porte.
VERSAO 1.0 PGINA 21

Dificuldade de aumentar ou diminuir a capacidade computacional de

acordo com a demanda atual de cada instituio. Normalmente, servido-
res de computao de grande porte possuem uma capacidade mxima de
expanso limitada por srie ou modelo do equipamento. Quando uma ins-
tituio atinge a capacidade mxima do modelo que utilizado, torna-se
necessrio realizar a troca do equipamento em operao por um modelo de
capacidade maior. Geralmente, os custos para a troca de modelo de equipa-
mento por um de maior capacidade so elevados.
Dependncia tecnolgica e de fornecedor devido utilizao de hardware

altamente especializado no modelo da computao de grande porte", os
quais somente a empresa que comercializa o equipamento ou o software
capaz de prestar suporte, realizar manuteno ou a venda de novos compo-
nentes. Isso leva ao controle do preo do mercado e enfraquece as relaes
de negociao entre governo e empresas para a obteno da melhor soluo
pelo menor custo possvel, influenciada pela reduo da competio entre
empresas no mercado.
Sistemas e hardwares heterogneos: existe no governo um parque computa-

cional extremamente heterogneo. Encontram-se em uso hardwares e softwa-
res dos mais variados fornecedores, muitas vezes incompatveis entre si,
devido ao emprego de padres fechados ou arquiteturas proprietrias.
Dificuldade de integrao e interoperabilidade entre os sistemas devido

abundncia de padres proprietrios, segmentados e divergentes, conjuga-
dos com a falta de padres abertos. A Administrao Pblica obrigada a
construir ou adquirir brokers10 , que funcionam como pontes entre tecnolo-
gias incompatveis, envolvendo muitas vezes o pagamento de licenas para
desenvolvimento das arquiteturas proprietrias utilizadas. Estes fatores di-
ficultam e muitas vezes retardam o processo de integrao nas arquiteturas
computacionais baseadas em mainframe e computadores de grande porte.
Neste cenrio o Governo Brasileiro tem desenvolvido diversos projetos objeti-

vando maior transparncia nas aes governamentais, otimizao do uso de re-
cursos pblicos, construo de processos democrticos entre governo, empresas
e cidados. Alguns exemplos so:
10
Midlerware de integrao e comunicao.
VERSAO 1.0 PGINA 22

Sistema eleitoral com votao e apurao atravs da utilizao de urnas ele-

trnicas;
Portal de Compras Governamentais11 e o Sistema Integrado de Adminis-

trao de Servios Gerais - SIASG, que so um conjunto de ferramentas
para operacionalizar internamente o funcionamento sistmico das ativida-
des inerentes ao Sistema de Servios Gerais12 , responsveis pelas compras
governamentais13 .
Arrecadao Fazendria: esta uma das reas mais avanadas em servios

de governo eletrnico no Brasil. A maioria dos servios e sistemas de arre-
cadao fazendria esto disponveis na Internet. A declarao de imposto
de renda de pessoa fsica disponibilizada por meio eletrnico atravs da In-
ternet e por disquete foi responsvel por 98,2% [256] do total de declaraes
no ano de 2005.
Projeto I 3 Gov 14 :
O Projeto I3 -Gov uma implementao da arquitetura referencial de inte-
roperao de sistemas - e-PING, atravs dele possvel acessar os Sistemas
Estruturadores de Governo, obtendo informaes de forma automtica e
interopervel. So disponibilizadas as seguintes informaes e servios: i)
Em Informao, possvel ver, por exemplo, o resultado dos gastos pbli-
cos com Sade, Educao e outros, sob a tica dos Programas e Aes de
Governo15 , ii) Em Inteligncia, esto registrados, de maneira padronizada,
os macroprocessos de gesto administrativa de Governo. Um exemplo o
11
http://www.comprasnet.gov.br
12
O Sistema Integrado de Administrao de Servios Gerais - SIASG, um conjunto informa-
tizado de ferramentas para operacionalizar internamente o funcionamento sistmico das ativida-
des inerentes ao Sistema de Servios Gerais - SISG, quais sejam: gesto de materiais, edificaes
pblicas, veculos oficiais, comunicaes administrativas, licitaes e contratos, do qual o Minis-
trio do Planejamento, Oramento e Gesto - MP o rgo central normativo.
13
O Governo Federal economizou R$ 637,8 milhes com a utilizao do prego eletrnico de
janeiro a julho de 2006. Esta modalidade foi responsvel por 47,3% do total de bens e servios
adquiridos pelo governo durante este perodo. Um estudo recente realizado pelo Banco Mundial
na rea de compras pblicas eletrnicas demonstra a eficincia do sistema de aquisies eletrni-
cas do Governo Federal Brasileiro. Segundo a avaliao do Banco Mundial, o Comprasnet obteve
pontuao mxima nos indicadores que avaliaram a transparncia na divulgao das licitaes e
de seus respectivos resultados e na utilizao de mtodos competitivos conforme recomendado
pela lei.
14
Integrao e Inteligncia em Informaes de Governo
15
O PPA, plano Plurianual estabelece, de forma regionalizada, as diretrizes, os objetivos e as
metas da Administrao Pblica Federal, e o principal instrumento de planejamento, por conse-
guinte, de mudana econmica e social com vistas ao desenvolvimento do Pas. O PPA organiza
a atuao governamental em programas e aes, inserindo na administrao pblica a orientao
do gasto pblico para resultados na sociedade.
VERSAO 1.0 PGINA 23

fluxo de aquisio de bens e de servios, iii) Em Integrao, ao implementar

a Arquitetura Referencial de Interoperao, so organizados os servios dos
Sistemas Estruturadores de Governo. O acesso s informaes utiliza meto-
dologia e arquitetura padronizadas que garantem a interoperao transpa-
rente e automtica16 .
Neste projeto esto envolvidas tecnologias de webservices, data warehouse,
OLAP, ETL e integrao de dados/sistemas.
Projeto de Qualidade de Informaes Sociais: O software de gesto de qua-

lidade de dados permite limpar, padronizar e cruzar os cadastros que utili-
zam dados como nome, data de nascimento, nome de pai e me e nmero
de documento de identificao.Tambm possibilita identificar erros de di-
gitao e fazer comparaes por similaridade. Reconhece, por exemplo, a
existncia de dois cadastros para uma nica pessoa que possui um regis-
tro com o nome completo e outro com apenas o ltimo sobrenome. Ou no
caso de uma mulher que se registrou no sistema com o nome de solteira e,
depois, com o nome de casada. As rotinas atuais no consideram essas di-
ferenas e permitem que uma pessoa receba duas vezes o mesmo benefcio.
Projeto Interlegis: O Interlegis um programa desenvolvido pelo Senado

Federal, em parceria com o Banco Interamericano de Desenvolvimento
(BID), de modernizao e integrao do Poder Legislativo nos seus nveis
federal, estadual e municipal e de promoo da maior transparncia e in-
terao desse Poder com a sociedade. Os meios utilizados so as novas
tecnologias de informao (Internet, videoconferncia e transmisso de da-
dos) que permitem a comunicao e a troca de experincias entre as Casas
Legislativas e os legisladores e entre o Poder Legislativo e o pblico, vi-
sando aumentar a participao da populao. Em funo das finalidades
do Programa o cadastro no Portal Interlegis aberto a qualquer pessoa,
dando a oportunidade a essas pessoas adicionarem contedo ao stio (pgi-
nas, imagens, links,notcias, ...), que sero avaliados pelos administradores
de contedo do Portal, para depois serem divulgados. O link Ajuda do
Portal"foi feito para facilitar a compreenso de como uma pessoa pode se
cadastrar, acessar e manusear os contedos que o Portal disponibiliza para
ela.
16
Ligao mquina a mquina sem interferncia de um operador (pessoa), com periodicidades
programadas e, se for o caso, com latncia zero. Rotinas administrativas de cadastro e habilitao
em servios disponibilizados mquina a mquina sem interferncia de um operador (pessoa),
com periodicidades programadas e, se for o caso, com latncia zero.
VERSAO 1.0 PGINA 24

G UIA DE C LUSTER 2.3.1 - C OMPUTAO SOB D EMANDA
Estes projetos desenvolvidos pelo governo possuem uma ou mais das seguintes
caractersticas:
Necessidade de Alta Capacidade de Processamento;
Suporte a Milhares de Usurios Simultneos;
Alta Capacidade de Armazenamento;
Alta Disponibilidade;
Segurana;
Utilizao de padres abertos;
Necessidade de integrao de sistemas e bases de dados.
Os grandes"sistemas utilizados pelo governo em sua maioria, como alguns dos

descritos anteriormente, so desenvolvidos para a utilizao em sistemas base-
ados em Computao de Grande Porte". A seo 2.4 apresenta uma descrio
sobre o paradigma computacional atualmente utilizado e a defesa de utilizao
do paradigma computacional de cluster e grid para atingir os mesmos resultados
com maiores vantagens para a Administrao Pblica.
2.3.1 Computao sob Demanda
Vrios sistemas de governo possuem demandas flutuantes, ou seja, durante um

momento convivem com pouca ou nenhuma carga de processamento e em outro
momento especfico possuem uma elevada carga de processamento.
Um exemplo deste perfil o sistema de declarao de imposto de renda. Durante

um perodo do ano ativada a entrada de dados no sistema para a realizao de
declaraes de imposto de renda. Quanto mais se aproxima o final deste perodo,
maior a quantidade de declaraes e, conseqentemente, a capacidade compu-
tacional necessria para o funcionamento do sistema. O mesmo ocorre com o
SIAPE, s que neste caso a utilizao para processamento e entrada de dados no
sistema ocorre com maior concentrao durante alguns dias do ms.
VERSAO 1.0 PGINA 25

G UIA DE C LUSTER 2.3.2 - A PROVEITAMENTO DE C ICLOS O CIOSOS
A arquitetura da computao de grande porte no possui capacidade para que

facilmente se aumente ou diminua seu poder computacional, sem esbarrar nas
barreiras impostas por seu hardware especializado e proprietrio, por conta de seu
alto custo total de propriedade e a dificuldade de aquisio destes equipamentos.
Em funo desta relao de dependncia, a administrao pblica obrigada a
adquirir um hardware com maior capacidade de processamento para atender a
demanda de pico de processamento do sistema. Durante quase toda a sua vida
til, o equipamento adquirido possuir capacidade de processamento ociosa, de-
vido s caractersticas de demandas flutuantes de processamento desses sistemas
governamentais.
Em resumo, a administrao alocar na maior parte do tempo recursos financei-

ros em um equipamento subutilizado, quando este recurso poderia ser utilizado
em reas com demandas mais urgentes.
Para equacionar questes como essas, a administrao pblica est em busca de

alternativas computacionais baseadas em Cluster e Grid que auxiliem na resolu-
o desse desafio de computao sob demanda, minimizando a capacidade de
processamento ociosa existente dentro da administrao pblica, bem como a
alocao de recursos financeiros desnecessrios.
2.3.2 Aproveitamento de Ciclos Ociosos
Estima-se que a administrao pblica direta possua um parque computacional

em torno de 300 mil estaes de trabalho, que adotam um padro de uso co-
mum. Este padro consiste numa maior utilizao destes equipamentos durante
os horrios de expediente comercial de trabalho. Entretanto, at mesmo durante
os horrios de maior utilizao destes equipamentos existem grandes perodos
de ociosidade do uso de processamento dos mesmos. Este imenso recurso com-
putacional ocioso poderia ser amplamente aproveitado atravs do emprego de
paradigmas de computao probabilstica e Grid Computing. Alguns possveis
usurios desta capacidade de processamento seriam: o governo atravs do pro-
cessamento e execuo de sistemas internos, e as universidades e centros de pes-
quisa atravs de projetos de pesquisa cientfica [272].
Existem diversos projetos mundiais de aproveitamento de recursos ociosos de
VERSAO 1.0 PGINA 26

G UIA DE C LUSTER 2.4 - D OIS PARADIGMAS C OMPUTACIONAIS
processamento que demonstram o poder da computao probabilstica. Alguns

exemplos so: SETI@home, que posteriormente deu origem ao BOINC17 , uma
infra-estrutura aberta de computao em rede; e o distributted.net18 , um projeto
de computao distribuda para finalidades genricas criado em 1997. Nestes
projetos so utilizados os ciclos ociosos de processamento de mquinas interliga-
das na internet, no dedicadas exclusivamente rede de processamento e disper-
sas mundialmente.
Uma lista extensa porm incompleta de projetos de aproveitamento de ciclos de

processamento ociosos pode ser encontrada na pgina:
http://en.wikipedia.org/wiki/List_of_distributed_computing_projects"
Existem no Brasil diversas atividades de pesquisa em andamento e solues de-

senvolvidas em universidades brasileiras que poderiam ser utilizadas para apro-
veitar a capacidade de processamento ocioso das milhares de estaes de tra-
balho do governo brasileiro. Algumas dessas solues so: o vCluster[147] e o
Ourgrid[62], desenvolvidos respectivamente pela Pontifcia Universidade Cat-
lica do Rio Grande do Sul e pela Universidade Federal de Campina Grande.
2.4 Dois Paradigmas Computacionais
O modelo atualmente adotado pelas empresas de informtica governamentais

e por muitas grandes empresas, para resolver o paradigma exposto na sesso
anterior, caracterizado principalmente pelos sistemas heterogneos de grande
porte, com a utilizao de mainframes e supercomputadores.
A evoluo das solues de Cluster e Grid vem criando uma nova alternativa
para os ambientes computacionais de grande porte. A utilizao de ambientes
clusterizados para computao de alta performance vem crescendo rapidamente
e j quase predominante para as grandes mquinas utilizadas nos dias de hoje.
17
Berkeley Open Infrastructure for Network Computing
http://boinc.berkeley.edu/
18
http://distributted.net
VERSAO 1.0 PGINA 27

G UIA DE C LUSTER 2.4.1 - C OMPUTAO DE G RANDE P ORTE
2.4.1 Computao de Grande Porte
A computao de grande porte definida como sistema de alta capacidade de

computao, tambm conhecida como Alta plataforma", esta caracterizada
pela utilizao de Mainframes e supercomputadores.
Mainframes so sistemas de computao, dedicados normalmente ao processa-

mento de um volume grande de informaes e transaes. Os mainframes so
capazes de oferecer servios de processamento a milhares de usurios atravs
de milhares de terminais conectados diretamente ou atravs de uma rede distri-
buda. So computadores que geralmente ocupam um grande espao fsico e ne-
cessitam de ambiente especial para seu funcionamento. Os mainframes so capa-
zes de realizar operaes em grande velocidade e sobre um volume muito grande
de dados. Os mainframes nasceram em 1946 e foram constantemente aperfeioa-
dos. Em 7 de abril de 1964, a IBM apresentou o System/360", mainframe que, na
poca, foi o maior projeto de uma empresa. Desde ento, outras empresas, como
a HP e a Burroughs (atual Unisys) lanaram seus modelos de mainframe.
Supercomputador um computador com altssima velocidade de processamento

e grande capacidade de memria, empregado em pesquisas cientficas e militares.
Este termo geralmente confundido com cluster, um tipo de supercomputador
criado a partir da cooperao de vrios computadores convencionais. Os pri-
meiros supercomputadores foram criados na dcada de 1960 por Seymour Cray.
Seymour Cray fundou sua prpria empresa, a Cray Research, em 1970 e dominou
o mercado da supercomputao durante 25 anos (1965-1990).
A distino entre supercomputadores e mainframes no clara e direta, mas ge-

nericamente so diferenciados pelas tarefas submetidas, os supercomputadores
so utilizados na soluo de problemas em que o tempo de clculo um limite
(processamento), enquanto os mainframes so utilizados em tarefas que exigem
alta disponibilidade, envolvem alta taxa de transferncia de dados (internos ou
externos ao sistema) e acessos simultneos (WikiPedia[389]).
A Figura 2.1, representa o problema de escalabilidade e dimensionamento decor-

rente da utilizao da computao de grande porte. A rea mais escura reflete
uma possvel evoluo da carga19 de processamento em um perodo de tempo.
19
A palavra carga utilizada nesta seo para representar o uso de recurso computacional, seja
VERSAO 1.0 PGINA 28

G UIA DE C LUSTER 2.4.1 - C OMPUTAO DE G RANDE P ORTE
Figura 2.1: Evoluo da carga de processamento e a utilizao da computao de grande porte.
Inicialmente, para responder uma demanda de carga de processamento C1

necessrio que a Administrao adquira uma soluo com capacidade de pro-
cessamento superior exigncia inicial. Essa medida justifica-se pelo j citado
alto custo do equipamento envolvido: uma vez que recursos financeiros sero
empregados na utilizao de mquinas multiprocessadas, interessante que es-
sas mquinas operem no maior tempo possvel. Dessa forma, para satisfazer a
demanda de processamento destacada em C1 , adquire-se uma soluo com ca-
pacidade C2 , superior, que ir garantir o funcionamento do ambiente at que a
exigncia de processamento atinja seu limite mximo. Na figura 2.1, a rea mais
clara representa a capacidade ociosa de processamento do equipamento utilizado
em funo do tempo.
Quando o limite de processamento do equipamento for alcanado, torna-se ne-

cessrio a realizao de um upgrade, que geralmente caracteriza-se pela substitui-
o do equipamento original por um novo, ou pela incorporao de novo hard-
ware ao equipamento original. Qualquer uma das alternativas exigir elevado
custo financeiro. Assim, passa-se utilizao de um equipamento com capaci-
dade de processamento C3 , para novamente garantir a operacionalizao do am-
biente por mais um perodo de tempo (T 1 at T 2), inaugurando um ciclo cons-
de processamento, rede e armazenamento.
VERSAO 1.0 PGINA 29

G UIA DE C LUSTER 2.4.2 - C OMPUTAO D ISTRIBUDA
tante de atualizaes determinado pela carga de processamento a ser suportada.
No caso da utilizao da computao de grande porte, percebe-se que as solues

adquiridas operam a maior parte do tempo com carga de processamento inferior
sua capacidade, devido ao alto custo de hardware associado dificuldade de
dimensionamento do ambiente, conforme representado pela rea mais clara na
Figura 2.1 e normalmente quando atingem a carga mxima, sofrem dificuldades
de expanso do hardware(capacidade de processamento).
Portanto, em ltima instncia, a Administrao aloca recursos financeiros em

uma soluo cuja capacidade de processamento no ser plenamente exigida na
fase inicial de alocao de recursos computacionais.
2.4.2 Computao Distribuda
Por utilizar componentes fsicos comuns em sua arquitetura, um ambiente cluster

apresenta facilidade de dimensionamento da capacidade de processamento. O
ambiente pode ser concebido de acordo com a exigncia inicial da carga de pro-
cessamento do ambiente. medida que a carga aumenta, novos componentes
fsicos podem ser facilmente alocados no ambiente para suprir a necessidade de
processamento. Como nestes ambientes podem ser empregados hardwares mais
abertos, ou utilizados pelo mercado, consegue-se realizar um rpido dimensio-
namento com custo reduzido, maximizando a capacidade de processamento do
ambiente.
A Figura 2.2 apresenta o resultado da utilizao do ambiente cluster. Para efeito

de ilustrao foram utilizados os mesmos parmetros da Figura 2.1 (relativa
adoo da computao de grande porte). As linhas em vermelho representam a
evoluo do dimensionamento da carga de processamento do ambiente cluster.
2.4.3 Comparao: Grande Porte e Distribuda
Existem similaridades e diferenas entre os ambientes de grande porte e os de

computao distribuda. Embora os ambientes de computao distribuda sejam
VERSAO 1.0 PGINA 30

G UIA DE C LUSTER 2.4.3 - C OMPARAO : G RANDE P ORTE E D ISTRIBUDA
Figura 2.2: Evoluo da carga de processamento e a utilizao da soluo de processamento dis-

tribudo.
mais recentes e tenham arquitetura computacional mais moderna, alguns especi-

alistas cogitam uma volta ao passado do grande porte.
Existem grandes similaridades entre as arquiteturas de computao de grande

porte e a computao distribuda. Por exemplo, os dois ambientes precisam de
uma estrutura fsica complexa, no que tange a: segurana e controles de acesso
ao ambiente, de refrigerao do ambiente e a organizao semelhante do espao.
Algumas dessas similaridades so:
Alto Poder de Processamento;
Alta Disponibilidade;
Suporte a Milhares de Transaes e Usurios simultneos;
Contingenciamento de recursos;
Administrao do ambiente operacional;
Grande Capacidade de Armazenamento.
VERSAO 1.0 PGINA 31

G UIA DE C LUSTER 2.4.3 - C OMPARAO : G RANDE P ORTE E D ISTRIBUDA
Informaes detalhadas sobre como implementar estas funcionalidades em ar-

quiteturas distribudas podem ser encontradas nos captulos: Cluster de Arma-
zenamento (captulo 7), Cluster de Aplicao (captulo 8), Cluster de Banco de
Dados (captulo 9), Cluster de processamento (captulo 10), Grid computing (cap-
tulo 13) e Virtualizao de Recursos (captulo 14).
A tabela 2.1 apresenta as principais diferenas entre as duas abordagens tecnol-

gicas tratadas na seo 2.4.
Grande Porte Cluster e Grid
- Alto custo de implantao; - Baixo custo de implantao;
- Dependncia de fornecedor - Independncia de fornecedores

nico; facilidade de negociao;
- Utilizao de hardware espec- - Utilizao de hardware comum

fico; padro PC;
- Alto custo de manuteno; - Baixo custo de manuteno;
- Dificuldade de redimensiona- - Facilidade de redimensiona-

mento do ambiente; mento do ambiente;
- Utilizao parcial da capacidade - Maximizao da capacidade de

de processamento; processamento;
- Grande custo total de proprie- - Baixo custo total de proprie-

dade; dade;
- Tecnologia estabelecida no mer- - Tecnologia inovadora.

cado.
Tabela 2.1: Diferenas entre computao de grande porte e distribuda
VERSAO 1.0 PGINA 32

G UIA DE C LUSTER 2.4.4 - A S G ERAES DA C OMPUTAO D ISTRIBUDA
2.4.4 As Geraes da Computao Distribuda
Durante os ltimos 20 anos, a computao distribuda passou por um processo

intenso de mudanas e revolues. Este processo foi marcado por 5 geraes
computacionais descritas a seguir:
Primeira Gerao de Computao distribuda:

A primeira gerao, tambm conhecida como host-based computting, ba-
seada na utilizao de terminais burros que servem apenas como meio de
visualizao de aplicaes, softwares e dados que encontram-se no compu-
tador central. Os recursos computacionais de processamento e armazena-
mento utilizados nesta gerao so exclusivamente do computador que hos-
peda as aplicaes.
Segunda Gerao de Computao distribuda:

Na segunda gerao, passam a ser utilizados computadores clientes com
pequena capacidade de processamento, capazes de suportar a emulao de
terminal, entretanto, as aplicaes continuam sendo armazenadas e execu-
tadas em um servidor remoto.
Terceira Gerao de Computao distribuda:

A terceira gerao caracterizada pelo utilizao do paradigma de cliente
e servidor, as aplicaes so desenvolvidas para serem parcialmente exe-
cutadas em um computador cliente, terem uma interface com o usurio e
interagirem com servidores de aplicao.
Quarta Gerao de computao distribuda:

A quarta gerao caracterizada pela utilizao de aplicaes multi-
camadas com regras de negcio, interface de usurios e dados separadas
entre ambiente de interao do usurio e vrias camadas de servidores.
Quinta gerao de computao distribuda:

A quinta gerao, tambm conhecida como grid computing, caracterizada
pela existncia e pela utilizao por parte do cliente de recursos computa-
cionais alocados em um pool virtual, de forma que o cliente utiliza ca-
pacidade computacional de acordo com a sua necessidade, sem precisar ter
maiores detalhes ou controle de onde esto os recursos utilizados.
VERSAO 1.0 PGINA 33

G UIA DE C LUSTER 2.4.4 - A S G ERAES DA C OMPUTAO D ISTRIBUDA
Da mesma forma que em cada uma destas inovaes aconteceu mudanas estru-
turais nas relaes entre as pessoas (usurias ou desenvolvedores de tecnologias)
e os sistemas computacionais, bem como nas concepes de desenvolvimento e
aplicao de sistemas informatizados, o mesmo ir ocorrer na adoo de tecnolo-
gias em Cluster e Grid. No existe tecnologia pior ou melhor do ponto de vista
global, cada tecnologia possui seu nicho de utilizao e aplicao. Caber aos ges-
tores dos sistemas realizar as devidas anlises para verificar quais procedimentos
devero ser tomados, tanto para a migrao ou desenvolvimento de aplicaes,
quanto para evitar gastos dispendiosos e criar um ambiente propcio para a utili-
zao destas tecnologias.
VERSAO 1.0 PGINA 34

Parte II
Aspectos Gerenciais
VERSAO 1.0 PGINA 35

Captulo 3
Introduo
O uso das tecnologias de Cluster e Grid tem aumentado nos ltimos 20 anos,
principalmente em aplicaes de pesquisa, algumas das reas de maior utilizao
destas tecnologias so: pesquisa gentica, bioinformtica, fsica, qumica, enge-
nharia, climatologia, petroqumica, pesquisa espacial e resoluo de equaes e
mtodos matemticos.
Apesar das tecnologias de clusters serem recentes, sua utilizao crescente e j

domina a lista das mquinas mais rpidas do mundo. A figura 3.1 mostra a evo-
luo percentual das arquiteturas de sistemas de alto desempenho no mundo,
onde os sistemas classificados como Clusters j so responsveis por 72, 80% dos
ambientes de supercomputao classificados na lista. Os dados so da organiza-
o top500.org [364].
Assim como as arquiteturas de cluster vem crescendo, a utilizao de software

livre (GNU/Linux) tambm vem crescendo de forma progressiva. A figura 3.2
mostra a evoluo de sua utilizao nos ltimos anos.
VERSAO 1.0 PGINA 36

G UIA DE C LUSTER CAPTULO 3 : I NTRODUO
Figura 3.1: Evoluo da utilizao de Arquiteturas de alto desempenho. Fonte Top500.org
Figura 3.2: Evoluo da utilizao de S.O. Fonte Top500.org
O mercado corporativo tem percebido as vantagens e possibilidades de negcios

relacionadas a utilizao de tecnologias baseadas em Cluster e Grid, sendo ob-
servado um crescimento da adoo destas tecnologias nesse mercado. Este fato
pode ser analisado pelo investimento para desenvolvimento destas tecnologias
realizado pelas maiores empresas de tecnologia do mundo, como Oracle, Goo-
gle, IBM, Intel, AMD, Sun, Cisco, entre outras, somado ao aumento da demanda
por arquiteturas computacionais alternativas. Uma pesquisa realizada no ano de
VERSAO 1.0 PGINA 37

G UIA DE C LUSTER CAPTULO 3 : I NTRODUO
2004 pelo instituto Forrest Research1 constatou que 37% das grandes empresas
do mercado corporativo esto em alguma fase de adoo/desenvolvimento de
projetos baseados em tecnologias de Grid Computing.
A organizao Top500 tambm mantm os dados sobre os segmentos corpora-

tivos que utilizam as mquinas de maior capacidade computacional do mundo,
a figura 3 mostra a evoluo no tempo desses segmentos de utilizao.
Figura 3.3: Evoluo da utilizao por segmento de mercado. Fonte Top500.org
A utilizao de computao distribuda no governo federal tem sido pequena,

devido entre outros fatores :
Quebra de paradigma de desenvolvimento de sistemas;
Lentido para absorver as novas tecnologias;
Falta de documentao em portugus;
Falta de treinamento em novas tecnologias.
1
Forrester, 2004. http://www.forrester.com/go?docid=34449
VERSAO 1.0 PGINA 38

G UIA DE C LUSTER 3.1 - VANTAGENS T CNICAS DE U TILIZAO DE C LUSTER E G RID
Em decorrncia da baixa adoo dessas tecnologias na rea governamental, esta

parte do documento aborda as principais tecnologias de Cluster e Grid e suas
possibilidades de utilizao no ambiente do Governo Federal, com o objetivo de
estimular a utilizao destas tecnologias no governo.
3.1 Vantagens Tcnicas de Utilizao de Cluster e

Grid
A sesso 2.3 apresenta algumas demandas e desafios computacionais do Governo

Brasileiro e a possibilidade de utilizao de tecnologias baseadas em cluster e grid
para auxiliar no atendimento destas demandas. Assim observa-se que utilizao
destas tecnologias nos ambientes do governo possui as seguintes vantagens tc-
nicas:
Utilizao de hardware padro de mercado em sistemas crticos atravs da

transferncia do gerenciamento das funes de alta disponibilidade, tole-
rncia falhas e balanceamento de carga do hardware para o software. Di-
minuindo a necessidade de hardware especializado, aumentando a concor-
rncia entre as empresas fornecedoras e propiciando ao governo a indepen-
dncia tecnolgica de fornecedores de hardware.
Em geral, as tecnologias de Cluster e Grid possuem como base padres

abertos e interoperveis. Facilitando a integrao de sistemas baseados nes-
tas tecnologias, em oposio a sistemas em computao de grande porte
que utilizam, em sua grande parte, tecnologias proprietrias e padres fe-
chados.
Disponibilidade de solues baseadas em software livre que permitem a

implementao de sistemas de cluster e grid sem a necessidade de nus de
licenas de software, alm de permitir a melhoria, alterao, distribuio e
compartilhamento de solues, segurana, transparncia e possibilidade de
auditoria plena do sistema.
Maior Facilidade de aumentar ou diminuir a capacidade computacional de

acordo com a demanda existente, utilizando Grids e Clusters computacio-
nais. Esta questo foi abordada no relatrio de Avaliao de Ferramenta de
VERSAO 1.0 PGINA 39

G UIA DE C LUSTER 3.2 - A RQUITETURA PARA SISTEMAS CRTICOS ONLINE EM N C AMADAS
Minerao - Tamandu, que encontra-se disponvel para download no en-

dereo: http://guialivre.governoeletronico.gov.br/labcluster/
tamandua.pdf
Possibilidade do desenvolvimento de sistemas e servios que utilizem os

conceitos de computao sob demanda, com o objetivo de aproveitar da
melhor maneira possvel os sistemas e recursos computacionais existentes
no governo.
Possibilidade de realizar o aproveitamento de ciclos ociosos de compu-

tadores j existentes na infra-estrutura de TI atual. Este assunto pode ser
melhor visto na sesso 2.3.2.
3.2 Arquitetura para sistemas crticos online em N

Camadas
A Arquitetura para sistemas crticos online em N camadas um conceito que

vem ganhando credibilidade no mercado. Em sistemas voltados para servios
web, suas principais vantagens so a estrutura baseada totalmente em padres
abertos e da arquitetura extremamente modular, capaz de se adaptar aos mais
diversos cenrios computacionais.
Tal arquitetura conjugada por N Camadas e pode ser composta geralmente por:
Camada de Aplicao Web
Camada de Banco de Dados
Camada de Armazenamento
Cada uma destas camadas ser melhor exemplificada nas subsees abaixo:
VERSAO 1.0 PGINA 40

G UIA DE C LUSTER 3.2.1 - C AMADA DE A PLICAO
3.2.1 Camada de Aplicao
Esta camada responsvel pelos servios web disponveis no cluster. nela que
se encontram os servidores de aplicao e a nica camada acessada externa-
mente pelos usurios dos servios.
Nesta camada so utilizadas tecnologias de Cluster de Aplicao, Balanceamento

de Carga e Alta Disponibilidade. A tabela D apresenta uma lista das tecnologias
utilizadas.
As principais caractersticas so: Alta Disponibilidade, Escalabilidade, Balancea-

mento de Carga, Alta Performance.
3.2.2 Camada de Banco de Dados
Esta camada responsvel pelos bancos de dados que so acessados pelos servi-
os disponveis no Cluster e onde se encontram os servios de Banco de Dados.
Nesta Camada so utilizadas tecnologias de Cluster de Banco de Dados e Replica-

o de Banco de Dados. A tabela D apresenta uma lista das tecnologias utilizadas.
As principais caractersticas so: Alta Disponibilidade, Balanceamento de Carga,

Alta Performance e Integridade dos Dados.
3.2.3 Camada de Armazenamento
Esta camada responsvel pela consolidao do armazenamento do Cluster, ela

deve simular/funcionar como um storage externo onde se encontram os servido-
res de Armazenamento.
Nesta Camada so utilizadas tecnologias de Distributed Mass Storage, Sistemas de

arquivos compartilhados, Dispositivos de Blocos em rede, entre outras. A tabela
D apresenta uma lista das tecnologias utilizadas.
VERSAO 1.0 PGINA 41

G UIA DE C LUSTER 3.2.4 - D IAGRAMA DA ARQUITETURA PROPOSTA
As principais caractersticas so: Tolerncia falhas, Alta Disponibilidade, Inte-

gridade dos Dados, Alta Performance e Arquivos Distribudos.
3.2.4 Diagrama da arquitetura proposta
A figura abaixo apresenta um diagrama da arquitetura proposta na seo 3.2

Balanceamento Internet
Internet
Cluster principal
Cluster espelho
Balanceamento
carga
carga
de
de
Switch
Switch
Aplicaao
Aplicaao
Switch
Switch
Switch
Switch
Banco de dados
Banco de dados
Switch
Switch
Balanceamento
Balanceamento
Link de backup
carga
carga
de
de
Switch
Switch
Armazenagem
Armazenagem
Switch
Switch
Figura 3.4: Esquema do modelo de cluster proposto.
VERSAO 1.0 PGINA 42

G UIA DE C LUSTER 3.2.5 - C ONSIDERAES SOBRE A ARQUITETURA
3.2.5 Consideraes sobre a arquitetura
A arquitetura em N camadas foi pensada para que fosse o mais geral e modular
possvel, alguns exemplos de utilizao desta arquitetura podem ser definidos
com os seguintes tipos de implementaes:
Camada de aplicao atravs de tecnologias de cluster, camada de banco de

dados atravs de uma mquina RISC de grande Porte e camada de armaze-
namento em Cluster, ou.
Camada de aplicao atravs de mquina RISC grande porte e/ou Main-

frame, camada de banco de dados em Cluster, camada de armazenamento
atravs do uso de Storage Externo, ou.
Implementao da camada de aplicao, banco de dados e armazenamento

em Cluster;
Alm de outras variaes de arquiteturas possveis.
3.3 Possibilidades de Aplicaes Prticas de Cluster

e Grid
A adoo de tecnologias em Cluster e Grid muitas vezes poder impactar nas

relaes entre as pessoas (usurios ou desenvolvedores de tecnologias) e os siste-
mas computacionais, da mesma forma que qualquer outra mudana tecnolgica.
Os gestores, juntamente com os tcnicos, devero definir qual tecnologia ser
adotada, quando adotar e sobre qual metodologia/procedimento atravs de uma
anlise prvia dos possveis benefcios obtidos com a mudana tecnolgica e os
riscos/impactos envolvidos.
O Governo Brasileiro possui vrias aplicaes e demandas computacionais dis-

tintas. Entretanto, existem necessidades ou caractersticas que so comuns a mai-
oria das aplicaes:
Alta Disponibilidade: a indisponibilidade de alguma aplicao de governo
VERSAO 1.0 PGINA 43

G UIA DE C LUSTER 3.3 - P OSSIBILIDADES DE A PLICAES P RTICAS DE C LUSTER E G RID
acarretar desde uma interrupo na execuo das atividades internas, at

mesmo, uma impossibilidade de servios prestados aos cidados. Por este
motivo, uma demanda transversal e comum para os sistemas e aplicaes
de governo que eles possuam algum tipo de sistema de alta disponibili-
dade e tolerncia falhas. Na computao de grande porte tais sistemas so
implementados em hardware altamente especializado.
Segurana: a demanda de segurana deve ser entendida como:
Confidencialidade: o acesso a informao dever ser realizado to so-

mente s entidades autorizadas, ou seja, quelas legitimamente defini-
das pelo proprietrio da informao.
Integridade: a informao manipulada deve manter todas as carac-

tersticas originais estabelecidas pelo proprietrio da informao, in-
cluindo controle de mudanas e garantia do seu ciclo de vida (nasci-
mento, manuteno, arquivamento e destruio).
Disponibilidade: a informao deve estar sempre disponvel para o

uso legtimo, ou seja, por aqueles usurios autorizados pelo propriet-
rio da informao.
Utilizao de Padres Abertos: crescente necessidade de utilizao de pa-

dres abertos e comuns entre as diferentes arquiteturas de aplicaes com
o objetivo de facilitar a integrao de sistemas, bases de dados e diminuir
a dependncia de tecnologias proprietrias. A e-ping2 define os padres
adotados, recomendados e em transio que devero ser utilizados pelo go-
verno brasileiro.
Aderncia Legislao: sistemas e aplicaes de governo necessariamente

devem estar de acordo com a legislao vigente no pas.
A definio de solues tecnolgicas, ou at mesmo a realizao de uma anlise

do ambiente computacional do governo complicada, devido a heterogeneidade
e diversidade tecnolgica existente. Desta maneira, preciso realizar uma anlise
de cada cenrio e aplicao, para poder definir quais tecnologias sero capazes
de atender as demandas da instituio com o melhor custo-benefcio.
2
Mais informaes sobre a e-Ping podem ser obtidas na sesso 2.2.2
VERSAO 1.0 PGINA 44

G UIA DE C LUSTER 3.3 - P OSSIBILIDADES DE A PLICAES P RTICAS DE C LUSTER E G RID
O uso de tecnologias de Cluster e Grid para aplicaes crticas no governo, pode

representar uma reduo nos custos, viabilizao da implementao de novos sis-
temas e ampliao da capacidade computacional dos sistemas existentes, devido
principalmente a utilizao de hardware commodity, de software livre e a questo
estratgica da independncia tecnolgica e de fornecedor.
Existem tecnologias de Cluster e Grid para as mais variadas finalidades, sendo

necessrio realizar uma anlise, e conseqente verificao de quais tecnologias
so capazes de atender as demandas computacionais existentes na instituio,
com o melhor custo-benefcio e o menor risco possvel continuidade do negcio.
Entretanto, podemos observar que alguns sistemas governamentais esto aptos

para uma possvel adequao:
o Sistema Integrado de Administrao de Recursos Humanos (SIAPE3 ): Sis-

tema responsvel pela gerao e processamento da folha de pagamentos
dos funcionrios da administrao pblica federal. Atualmente, este sis-
tema funciona em um computador de grande porte que centraliza o pro-
cessamento de todas as folhas de pagamento da administrao pblica fe-
deral. Teoricamente, o processamento de uma folha de pagamento de dois
funcionrios distintos no possui interdependncia entre si e poderia ser
realizado de forma distribuda utilizando-se tecnologias de processamento
paralelo ou Grid Computing" do tipo bag-of-tasks. Esta abordagem pode-
ria utilizar equipamentos dedicados distribudos ou at mesmo aproveitar
os recursos ociosos das estaes de trabalho do governo federal, eliminando
a necessidade e os custos envolvidos na aquisio e manuteno do main-
fraime utilizado atualmente por este sistema.
Sistema Integrado de Administrao Financeira do Governo Federal - SI-

AFI4 : O SIAFI o principal instrumento utilizado para registro, acompa-
nhamento e controle da execuo oramentria, financeira e patrimonial do
Governo Federal. Atualmente, este sistema executado em mainfraime e
encontra-se em andamento no Servio Federal de Processamento de Dados
(Serpro) um projeto[201] de migrao para baixa plataforma, adoo de soft-
ware livre e tecnologia de Cluster de balanceamento de carga.
3
http://www.siapenet.gov.br
4
http://www.tesouro.fazenda.gov.br/SIAFI/
VERSAO 1.0 PGINA 45

G UIA DE C LUSTER 3.3.1 - C ENRIO - A PLICAES WEB
Para efeitos didticos e de esclarecimento das possibilidades de utilizao de tec-

nologias de Cluster e Grid no Governo Federal, sero definidas alguns cenrios
bsicos diferentes onde sero apresentadas caractersticas das aplicaes, deman-
das computacionais e uma pequena anlise sobre quais tecnologias podero ser
utilizadas. Para informaes tcnicas sobre as tecnologias de Cluster e Grid abor-
dadas neste documento, leia a parte III.
3.3.1 Cenrio - Aplicaes WEB
Neste cenrio, a instituio da administrao pblica possui um portal web de

servios voltados aos cidados, sendo utilizado basicamente para realizar con-
sultas e obter informaes, possuindo contedo esttico (armazenado localmente
em sistema de arquivos) e contedo dinmico (armazenado remotamente atravs
da utilizao de um servidor de banco de dados).
O portal precisa estar disponvel para acesso e consulta dos usurios ininterrup-
tamente, as questes como integridade, confidencialidade e autenticidade so es-
senciais, pois as informaes contidas no portal no devem ser alteradas e dispo-
nibilizadas para pessoas que no possuam a devida autorizao.
A tabela 3.1 apresenta o ms, a quantidade de acessos simultneos ao portal e a

carga de processamento utilizada no computador que hospeda a aplicao.
Ms Acessos Carga
Simul- Utili-
tneos zada
01 250 50%
02 350 70%
03 450 90%
04 500 100%
Tabela 3.1: Tabela Cenrio 1
Neste cenrio, aps o servidor atingir sua capacidade de processamento mxima
VERSAO 1.0 PGINA 46

G UIA DE C LUSTER 3.3.1 - C ENRIO - A PLICAES WEB
em 4 meses ser necessrio, caso seja possvel, realizar otimizaes na aplicao,

para continuar utilizando o mesmo servidor por mais tempo ou realizar um up-
grade na capacidade computacional do servidor. Aps atingir o limite tcnico de
expanso do servidor dever, ser adquirida uma mquina com maior capacidade
de processamento.
Normalmente, quanto maior a capacidade de processamento de um nico servi-

dor maior ser o preo, sendo que o custo envolvido na aquisio no cresce de
maneira linear e o preo de uma mquina com 4 processadores maior que preo
de duas mquinas de 2 processadores cada. Apesar disso, uma mquina de 8 pro-
cessadores ter um desempenho menor que duas mquinas de 4 processadores
devido as caractersticas e limitaes fsicas da arquitetura x86_32 e x86_64. Sabe-
se que nestas arquiteturas computacionais a melhor relao custo/performance
so obtidas em mquinas de 4 processadores.
Caso a demanda continue crescendo, em pouco tempo, uma nica mquina na ar-
quitetura x86_32 e x86_64 no ser capaz de atender as necessidades computaci-
onais. Neste caso, existiro duas possibilidades: trocar a arquitetura da mquina
utilizada, ou distribuir a demanda computacional em mais de um servidor.
A abordagem tradicionalmente utilizada seria a primeira e tem apresentado al-

guns problemas tais como: alto custo, dependncia tecnolgica e de fornecedor e
conseqente dificuldade de administrar o ambiente de TI.
Para se realizar a ampliao da capacidade computacional de acordo com a se-

gunda possibilidade, distribuindo o atendimento da demanda em mais de um
servidor, devero ser utilizadas tecnologias e solues para a implementao de
Cluster ou Grid.
Neste cenrio de portal ou aplicao web, podero ser utilizadas tecnologias de

alta disponibilidade (para garantir que o nvel de servio exigido) e balancea-
mento de carga (para distribuir as requisies dos usurios entre os servidores).
Estas tecnologias podem ser utilizadas em conjunto ou separadamente de acordo
com a necessidade da instituio. Exemplos de possibilidade so:
Implementar somente um sistema de alta disponibilidade com duas mqui-

nas:
VERSAO 1.0 PGINA 47

G UIA DE C LUSTER 3.3.2 - C ENRIO - M INERAO DE D ADOS
A capacidade de processamento dever ser suportada trivialmente por ape-

nas uma mquina. Uma das tecnologias mais utilizadas nesta possibilidade
o HeartBeat, vide 8.3.
Implementar somente um sistema de balanceamento de carga para vrias

mquinas:
As requisies dos usurios ser balanceada entre as diversas mquinas.
Entretanto, razovel que o sistema seja capaz de no direcionar uma requi-
sio de um usurio para uma mquina defeituosa. Uma tecnologia ampla-
mente utilizada para balanceamento de carga o LVS - Linux Virtual Server
(vide 8.1).
Implementar um sistema de alta disponibilidade e de balanceamento de

carga:
As requisies de usurios sero distribudas em um conjunto de servidores
e caso ocorra falha em algum dos servidores, o mesmo no receber mais
requisies de usurios. As tecnologias mais utilizadas para implementar
solues deste tipo so : lvs+ldirectord, vide 8.1.
Assim, preciso garantir que a informao ser a mesma no importando qual

servidor ela estar sendo acessada, de forma que todo o contedo publicado,
seja ele esttico ou dinmico, dever estar disponvel, sincronizado e idntico em
todos os servidores. Solues para esses problemas so a utilizao de sistemas
de arquivos distribudos e compartilhados, como o GFS, OCS2 e PVFS.
Informaes mais detalhadas sobre estas tecnologias sero apresentadas no cap-

tulo 8.
3.3.2 Cenrio - Minerao de Dados
Nos ltimos anos, a informatizao dos meios de produo e as novas formas

de comunicao possibilitaram a gerao de grandes volumes de dados nas mais
diversas instituies, sejam pblicas ou privadas. Grande parte das informaes
armazenadas nessas bases de dados permanece ainda desconhecida, uma vez que
as ferramentas tradicionais de extrao no permitem uma completa visualizao
de todas as correlaes possveis, tornando o processo demorado, dispendioso e
pouco automatizado.
VERSAO 1.0 PGINA 48

G UIA DE C LUSTER 3.3.2 - C ENRIO - M INERAO DE D ADOS
O aproveitamento de tais informaes armazenadas permite o desenvolvimento

de estratgias que possibilitam aumentar a competitividade das organizaes.
Especificamente para o setor pblico, a produo de conhecimento a partir das
bases de dados propicia melhor suporte tomada de deciso, tendo por con-
sequncia a promoo da eficincia da administrao.
Nesse contexto, a automatizao dos processos de anlise de dados, com a uti-

lizao de software especfico, diretamente conectado massa de informaes,
tornou-se uma grande necessidade, a qual aplicao de tcnicas de minerao de
dados prope-se a dirimir. Minerao de dados compreendida como a explora-
o e a anlise, por meio automtico ou semi-automtico, de grandes quantidades
de dados, a fim de descobrir padres e regras significativos5 .
O processo de minerao de dados tem como principais objetivos descobrir rela-

cionamentos, geralmente no triviais, entre dados armazenados, fornecer subs-
dios para que seja possvel realizar previso de tendncias futuras com base nos
registros acumulados, bem como estabelecer parmetros para anlise e auditoria
das informaes coletadas.
A realizao de um processo de minerao de dados, geralmente emprega al-

goritmos de alta complexidade os quais podem realizar tarefas de classificao,
estimativa, associao, segmentao ou agrupamento de informaes, com pos-
sibilidade de consultas bases de dados no estruturadas.
Dessa forma, medida que a base de dados aumenta, as possibilidades de relaci-

onamentos e combinaes de tarefas cresce exponencialmente.
Por essa razo, existe o desafio de promover um ambiente computacional favor-

vel ao processo de minerao de dados para que os resultados possam ser obtidos
em curto espao de tempo.
Existem 2 tipos de Cluster que podem auxiliar na resoluo deste problema:
Cluster de Processamento de Alto Desempenho: Implementao dos algo-

ritmos de manipulao dos dados utilizando-se de tcnicas de explorao
de paralelismo e sistemas de processamento distribudo de alto desempe-
5
BERRY, M. J. A.; LINOFF, G. Data mining techniques for marketing, sales, and customer support.
John Wiley & Sons, New York, 1997.
VERSAO 1.0 PGINA 49

G UIA DE C LUSTER 3.3.3 - C ENRIO - P ROCESSAMENTO DE A LTO D ESEMPENHO
nho, com o objetivo de melhorar o tempo de minerao dos dados atravs

da distribuio das operaes realizadas entre um conjunto de servidores.
As principais tecnologias utilizadas para esta finalidade so: MPI, PVM e
SSI.
Cluster de Banco de Dados: A idia aqui clusterizar a camada de banco

de dados da aplicao, fornecendo a aplicao uma maior capacidade de
armazenamento disponvel e um acesso aos dados mais rpido. Estas ques-
tes so obtidas atravs da utilizao de tecnologias de banco de dados dis-
tribudo, replicado, ou paralelizao de consultas SQL. As solues mais
conhecidas para auxiliar na resoluo deste problema so: Mysql Cluster,
PgCluster, slony e Sequoia.
O Governo Federal financiou o desenvolvimento do tamandu, um software de

minerao de dados em cluster, este software foi licenciado sobre os termos de
licenciamento GPL. Permitindo a sua utilizao, distribuio, alterao e redis-
tribuio de verso alterada do software. O tamandu um servio web de mi-
nerao de dados, possui uma arquitetura escalar e modular, capaz de realizar
o processamento da minerao atravs de algoritmos de processamento paralelo
baseados na biblioteca de processamento paralelo PVM.
Maiores informaes sobre o software de minerao tamandu podem ser encon-

tradas na pgina oficial do projeto: http://tamandua.speed.dcc.ufmg.br/.
3.3.3 Cenrio - Processamento de Alto Desempenho
Aplicaes que demandam uma grande quantidade de recurso de processamento

podem obter ganhos expressivos se utilizarem paradigmas de programao pa-
ralela e sistemas de distribuio do processamento em cluster. Alguns exemplos
so: aplicaes de processamento cientfico, simulaes, anlises e comparaes
de dados/informaes, entre outras.
Atualmente existem dois principais tipos de cluster para processamento de alto

desempenho, sendo que cada um possui suas prprias caractersticas:
Bibliotecas de Programao Paralela: Neste tipo de cluster de processa-
VERSAO 1.0 PGINA 50

G UIA DE C LUSTER 3.3.3 - C ENRIO - P ROCESSAMENTO DE A LTO D ESEMPENHO
mento de alto desempenho necessrio adaptar o software para utilizar as

bibliotecas de programao paralela que compem o cluster. As bibliotecas
mais utilizadas so o MPI e o PVM. No simples portar aplicaes exis-
tentes para utilizar este tipo de cluster, pois a lgica computacional normal-
mente utilizada no desenvolvimento de sistemas ou aplicaes seqencial,
sendo preciso antes de mais nada realizar uma anlise da aplicao com o
objetivo de encontrar pontos no sistema de maior demanda computacional
e possibilidades de paralelizao, utilizando tcnicas de programao pa-
ralela e explorao do paralelismo de forma a obter o melhor desempenho
possvel em um cluster de processamento de alto desempenho (Vide sesso
5).
Sistema de imagem nica (SSI): Neste tipo de cluster de processamento de

alto desempenho, o sistema de imagem nica simula uma nica mquina
com todos os recursos computacionais das mquinas presentes no cluster.
Isto acontece geralmente de maneira transparente para as aplicaes e de-
pendendo do sistema utilizado, teoricamente, se a aplicao capaz de uti-
lizar mais de um processador ela ser capaz de ser utilizada no cluster sem
a necessidade de realizar alteraes na aplicao.
Os sistemas de SSI mais utilizados so: Mosix, openMosix, OpenSSI e Kehr-

righed. Cada um destes sistemas realiza a migrao de processos de maneira
diferenciada, no sendo possvel atualmente realizar a migrao de qualquer tipo
de aplicao ou processo, devido as limitaes de cada sistema. Entretanto, exis-
tem muitos casos onde a adaptao do sistema para execuo em um cluster de
processamento baseado em bibliotecas de programao paralela pode ser cus-
toso ou invivel e que possvel executar a aplicao em um cluster SSI, obtendo
um desempenho melhor que o da aplicao serial, entretanto no to otimizado
quanto se a aplicao fosse programada para ser paralela.
Um exemplo de aplicao que envolveria um grande esforo de adaptao e mi-

grao para um cluster de bibliotecas de programao paralela e que poderia ser
utilizado em um cluster SSI facilmente um programa de simulao que recebe a
entrada de diversas condies iniciais e demora 10 dias para retornar o resultado
da simulao. Em um cluster SSI, poderiam ser executadas vrias cpias do pro-
grama com arquivos de entrada e sada diferentes que seriam automaticamente
distribudos no conjunto de mquinas do cluster. Este tipo de aplicao no teria
nenhum ganho no tempo de processamento de uma cpia do programa pois o
VERSAO 1.0 PGINA 51

G UIA DE C LUSTER 3.3.4 - C ENRIO - A LTA D ISPONIBILIDADE
programa no paralelo, entretanto ao final do prazo de execuo teria-se um

acervo maior de resultados para posterior anlise e utilizao.
As tecnologias de processamento de alto desempenho devem ser utilizadas nas

seguintes situaes:
Caso a instituio no possuir recursos ou permisso para realizar altera-

es na aplicao. A aplicao pode obter ganhos na utilizao do sistema
de imagem nica sem necessidade de alterao.
Caso a melhoria de performance e resultados da paralelizao da aplicao

justifiquem a necessidade de adaptao e re-desenvolvimento da aplicao
explorando as possibilidades de paralelismo.
Atualmente a Petrobras a maior usuria de processamento de alto desempenho

em cluster no brasil, sendo que possui 3 dos 4 supercomputadores da Amrica
do Sul que encontram-se atualmente na lista 500 supercomputadores [364] mais
rpidos do Mundo. Estes 3 supercomputadores so clusters de processamento
de alto desempenho utilizados para a execuo de seus sistemas de explorao
petrolfera.
3.3.4 Cenrio - Alta Disponibilidade
Atualmente, sistemas de tecnologia da informao so responsveis pela execu-

o das mais variadas atividades administrativas, financeiras, de gesto de pes-
soas e at mesmo de comunicao na maioria das instituies pblicas. Este am-
biente, extremamente dependente dos sistemas de TIC, uma possvel falha ou
indisponibilidade em algum servidor ou servio, acarretar a impossibilidade de
realizar alguma atividade ou at mesmo prejuzo financeiro para a instituio.
Um fator importante a ser levado em considerao na preparao de infra-

estrutura para qualquer servio ou aplicao o fato de que todo e qualquer hard-
ware, software ou aplicao esto sujeitos a falhas. Sejam por conta de problemas
nos componentes eletrnicos, problemas de desenvolvimento do software/apli-
cao ou at mesmo erros resultantes de uma interao errada dos usurios ou
administradores do ambiente.
VERSAO 1.0 PGINA 52

G UIA DE C LUSTER 3.3.4 - C ENRIO - A LTA D ISPONIBILIDADE
Existem basicamente duas alternativas, do ponto de vista tecnolgico, para se

conseguir um maior nvel de disponibilidade:
1. Implementao de mecanismos de redundncia e tolerncia falhas no

hardware. Alguns exemplos so: Fontes Redundantes, Espelhamento de
discos, Utilizao de Tecnologias HotSwap para troca de componentes do
servidor, entre outras. Esta abordagem normalmente responsvel por au-
mentar os custos associados aquisio dos equipamentos de informtica.
2. Implementao de mecanismos de tolerncia falhas via software. Esta

abordagem consiste em utilizar um sistema de alta disponibilidade em soft-
ware, capaz de gerenciar um conjunto de servidores de forma que a falha
em algum dos servidores no afete a execuo da aplicao que controlada
pelo sistema de alta disponibilidade. Devido as questes relacionadas a alta
disponibilidade serem tratadas em software, em geral, podem ser adquiri-
dos hardwares commodity, normalmente com custo menor que os hardwares
utilizados na alternativa 1. Exemplos destes sistemas so: HeartBeat, Mon,
Carp, entre outros.
O sistema de alta disponibilidade com maior maturidade e mais utilizado no sis-

tema operacional linux o Heartbeat 8.3. Este sistema pode ser utilizado para
controlar a parada e o incio de servios ou a execuo de comandos em um
conjunto de mquinas. Em conjunto com o Heartbeat necessrio utilizar al-
guma tecnologia que seja responsvel por replicar e garantir a integridade dos
dados entre os dois ou mais servidores, em geral o software mais utilizado o
DRBD (vide 7.2.3).
A figura 3.5 um diagrama onde 4 clientes esto acessando uma aplicao que
encontra-se hospedada em um conjunto de alta disponibilidade. A aplicao
encontra-se ativa somente no servidor primrio e todos os dados salvos no disco
do servidor primrio so replicados para o servidor secundrio. Em caso de fa-
lhas no servidor primrio, o heartbeat ser responsvel por tomar as aes ne-
cessrias para que o servidor secundrio passe a executar a aplicao e servi-la
aos clientes. Os clientes enxergam apenas um servidor atravs de um endereo
ip compartilhado entre os dois servidores.
Esta soluo estvel, de implementao simples e utilizada em produo em

todo o mundo. Entretanto, uma requisio enviada ao servidor primrio antes de
VERSAO 1.0 PGINA 53

G UIA DE C LUSTER 3.3.5 - C ENRIO - B ANCO DE D ADOS
Figura 3.5: Sistema de alta disponibilidade com dois servidores sendo acessados por 4 clientes.
Um dos servidores Primrio(ativo) e outro Secundrio(passivo)
sua falha que envolva alguma atividade de escrita (email, banco de dados, ser-
vidor de arquivos, etc.) e no tenha sido gravada no disco do servidor primrio,
ser perdida quando o servidor secundrio assumir. Pois, o servidor secundrio
s possui as informaes que tiverem sido gravadas no disco do servidor prim-
rio e replicadas em seu disco.
Recomenda-se utilizar uma soluo baseada em heartbeat+drbd+mon em siste-

mas de email, servidor de arquivos, servidor web e banco de dados. Sendo que
devem ser tomados os devidos cuidados no sistema gerenciador de banco de da-
dos para que no sejam perdidas requisies de transao.
3.3.5 Cenrio - Banco de Dados
A camada de banco de dados uma das partes crticas da maioria dos sistemas.
Uma falha, indisponibilidade ou problemas de integridade na camada de banco
de dados pode ser responsvel pela indisponibilidade de um sistema inteiro ou
at mesmo pela perda de dados que encontravam-se armazenados. Por conta
desse motivo, esta camada deve ser avaliada, desenvolvida e implementada com
VERSAO 1.0 PGINA 54

G UIA DE C LUSTER 3.3.5 - C ENRIO - B ANCO DE D ADOS
cuidado.
Existem diversos cenrios em que as tecnologias de cluster para banco de dados

podem ser utilizadas, sendo que as principais podem ser classificadas em:
Alta Disponibilidade: Nesta categoria encontram-se as tecnologias de re-

plicao e alta disponibilidade. Para replicao normalmente utilizada
alguma soluo prpria ou especfica para o sistema de banco de dados
utilizado. No caso do postgres pode ser utilizado o slony (vide 9.3.3) que
prov replicao do tipo ativo/passivo. O mysql(vide 9.4) possui um re-
curso prprio para replicao de tabelas e dados entre servidores. Para alta
disponibilidade pode ser utilizado por exemplo o Heartbeat+DRBD.
Paralelizao de Consultas SQL: Nesta categoria encontram-se as tec-

nologias de paralelizao de consultas SQL, cujo objetivo aumentar
a velocidade de processamento e execuo de consultas sql complexas,
particionando-a e distribuindo em um conjunto de servidores. Uma soluo
independente de plataforma de banco de dados o Pargres6 , desenvolvido
para ser utilizado principalmente em aplicaes OLAP e Datawarehouse.
Distribuio do banco e balanceamento das requisies: Este tipo de tecno-

logia utilizada normalmente em grandes aplicaes transacionais, onde
necessrio aumentar a performance e disponibilidade. As solues mais co-
nhecidas so o pgCluster, especfico para o postgres e o Sequoia (vide 9.5.1),
soluo em java independente de sistema de gerenciamento de banco de
dados.
Maiores informaes sobre as tecnologias disponveis para cluster de banco de

dados podem ser encontradas no captulo 9.
6
http://http://pargres.nacad.ufrj.br/.
VERSAO 1.0 PGINA 55

Captulo 4
Viso Geral
4.1 A sensibilizao
A escolha por desenvolver um sistema crtico com arquitetura em cluster uma

deciso complexa e tem a sua sustentabilidade em muitos aspectos, no apenas
tcnicos, mas tambm estratgicos e econmicos e devem estar contextualizada
em uma poltica tecnolgica. A deciso sobre o desenvolvimento e o uso de Clus-
ters sofre tambm influncia de carter cultural, e esta pode ser mais limitadora
do que o prprio emprego da tecnologia.
Mudar sistemas, alterar solues e plataformas, em geral, no so tarefas trivi-

ais. Ao considerarmos que toda mudana capaz de modificar o comportamento
e as rotinas das pessoas aumenta o grau de dificuldade das tarefas, podemos afir-
mar que, ao se falar em inovao, a ateno dos Administradores no pode se
concentrar exclusivamente na parte tcnica. A inovao exige tambm esforo
de mudana cultural, o que nas organizaes se retrata diretamente no que se
concebe como Cultura Organizacional.
VERSAO 1.0 PGINA 56

G UIA DE C LUSTER 4.2 - O S R ECURSOS H UMANOS E NVOLVIDOS
4.2 Os Recursos Humanos Envolvidos
4.2.1 Aperfeioamento dos Tcnicos
Antes de capacitar a equipe tcnica e de desenvolvimento, preciso reun-los e

explicar os motivos da mudana de plataforma. importante conquistar todos
envolvidos no projeto e concientiz-los sobre os motivos que levaram a institui-
o a escolher essa nova tecnologia e as melhorias que essa mudana ir ocasio-
nar. Esta uma atividade essencial na chamada Sensibilizao.
Adotar uma nova tecnologia, como a de clusters, necessita de um plano de ca-

pacitao que contenha profissionais especializados para viabilizar a difuso do
conhecimento dessa tecnologia entre os funcionrios da instituio, para que es-
tes aceitem mais facilmente a implantao, absorvam o conhecimento nas regras
de negcio do sistema e possam manter todo o ambiente operacional sem a neces-
sidade e a dependncia de agentes externos. Antes da implantao necessrio,
identificar os perfis adequados com a tecnologia de clusters que ser implantada,
como por exemplo: sistemas distribudos, sistemas paralelos, banco de dados
distribudos, Grid e depois formar um programa de treinamentos de acordo com
essas reas.
4.2.2 Consultoria
A utilizao de Cluster no simples, e deve ser bem conhecida em todos os

nveis da organizao de TIC da instituio. A opo e o projeto de utilizao
desta tecnologia necessita de estudo e avaliao por todas as esferas, para que
possa ter sucesso e trazer benefcios instituio.
A contratao de uma consultoria especializada pode diminuir os riscos de erros

e gastos excessivos no projeto. Consultores especializados podem, em conjunto
com funcionrios da empresa, participar do planejamento, da avaliao das pos-
sibilidades de utilizao de tecnologias de clusters dentro do ambiente, analisar a
situao atual, indicar os pontos crticos do projeto. Esse processo de consultoria
VERSAO 1.0 PGINA 57

G UIA DE C LUSTER 4.3 - O P ROJETO DE C LUSTER
tem de prever uma interao dos conhecedores do problema"1 com os especi-

alistas em tecnologias de cluster para que em conjunto possam obter a melhor
soluo para os Sistemas previstos para rodar no ambiente clusterizado.
4.3 O Projeto de Cluster
No processo de preparao para projetar ou planejar um sistema que vai rodar

em Cluster para ambientes empresariais (ou ambientes de produo, que no so
flexveis como os ambientes acadmicos) aconselhvel se preparar para respon-
der e respaldar vrias tecnologias, metodologias e informaes. A opo por uma
ou outra tecnologia pode ser o marco divisor entre o sucesso ou no do projeto.
Assim, alguns cuidados precisam ser tomados na hora de reconhecer o ambiente
no qual se est optando.
Vrias dicas com foco apenas em sistemas de alto desempenho, so da-

das no artigo: Ten Tips for Building Your First High-Performance Clus-
ter" ou em traduo livre Dez macetes para construir seu primeiro Clus-
ter de Alto-desempenho" escrito por Joseph D. Sloan e publicado em
12/29/2004" na http://www.linuxdevcenter.com/pub/a/linux/2004/12/
29/lnxclstrs_10.html.
Assim, procuramos expandir a idia do artigo e tendo como foco estruturas em-
presariais mais complexas e tecnologias abertas.
Algumas caractersticas que devem ser observadas nesse modelo so:
Escalabilidade do ambiente: Capacidade sob demanda para atender os re-

quisitos de recursos de infra-estrutura;
Balanceamento de carga: Capacidade de realocar as cargas de trabalho no

caso de falhas dos sistemas, tanto de Hardware como de software, e tambm
aumentar o desempenho global do sistema;
Permitir separao de ambientes e ou aplicativos dentro de uma partio,

1
Pressupe-se nesse ponto que a instituio detm todo o conhecimento das regras de negcios
do seu ramo de atuao, tendo capacidade em modelar os sistemas necessrios a ela.
VERSAO 1.0 PGINA 58

G UIA DE C LUSTER 4.3.1 - O QUE DEVE SER OBSERVADO
para eliminar a conteno e alocar desempenho para sistemas especficos;
Gerenciamento da carga de trabalho, permisso para estabelecer critrios de

desempenho para cargas de trabalho especficas com base em suas regras de
negcios e ajustar os recursos de processamento para atingir estas metas.
Essas opes no s estimulam a eficincia econmica, mas tambm permitem

maior visibilidade de como os recursos de computao devem ser alocados para
apoiar processos de negcio estratgicos em tempo real, eliminando a subutiliza-
o e os custos indiretos dela decorrente.
4.3.1 O que deve ser observado
Como j observado, a construo deste tipo de sistema complexa e necessrio

conhecer muito bem o problema para propor a melhor soluo. Clusters de alto-
desempenho provem freqentemente o modo de melhor custo benefcio para
acelerar clculos, ou em outras palavras, a computao de alto desempenho, mas
a construo do primeiro Cluster pode ser uma experincia difcil. Os desafios
para a construo de uma infra-estrutura deste tipo grande e muitas variveis
tem de ser observadas e trabalhadas para se obter, alm do melhor desempenho,
um menor custo de investimento. O pensamento semelhante aos em sistemas
enterprise", mas com um grau de complexidade maior, pois estamos tratando
de um ambiente que tem de ser estvel, robusto, escalvel e capaz de responder
por toda a carga de processamento projetada.
O tempo de vida2 das aplicaes desenvolvidas para Clusters enterprise" tem

a tendncia de ser maior, podendo ter ciclos de mais de 10 anos de operao.
Nestes casos a escolha das tecnologias a serem usadas tero grande importncia
para as bases do projeto.
Entre muitas outras informaes e detalhes de projetos, alguns considerados mais

importantes so levantados e discutidos nas prximas sesses, a listar:
1. Estabelea metas realistas

2
Ciclo de vida e de desenvolvimento dos sistemas
VERSAO 1.0 PGINA 59

2. Projeto piloto
3. Utilizao hardware idntico
4. Sistemas diskless
5. A importncia da rede de comunicaes
6. Minimize mas no subdimensione seu hardware
7. Isole seu Cluster
8. Use ferramentas de Cluster
9. Supere o desejo do mais recente
10. Plano para expanso e reposio desde o princpio
11. Documente seu Cluster
12. Segurana
13. Aplicao
14. Banco de dados
Estabelea metas realistas
O primeiro passo na construo de um Cluster de alto-desempenho realizar

um planejamento visando o que se pretende estruturar e decidir quais as metas
a serem atendidas, tanto no curto como no longo prazo. preciso selecionar
o hardware apropriado e determinar de quais softwares previstos para o ambiente.
Claramente, estas decises afetaro seu planejamento. Por exemplo, para clculos
intensivos em dados, necessrio um subsistema de I/O de grande capacidade e
desempenho, mas em ambientes WEB a resposta dos servidores WEB pode ser a
mtrica, j para banco de dados a quantidade de transaes suportadas.
No aconselhvel iniciar o desenvolvimento da aplicao e nem do Cluster,

antes de conhecer seu problema. Faa um levantamento de seus sistemas e tenha
pessoas que conheam ambas as reas para participar do projeto do Cluster.
VERSAO 1.0 PGINA 60

Em caso de aplicaes existentes, que se queira portar para este ambiente, pes-
quise as possibilidades pois, certamente, o porte de aplicaes mais antigas (le-
gados) custar muito mais caro do que o desenvolvimento de uma nova aplicao
em tecnologias mais recentes. Mas ainda sim, a avaliao de cada uma aplicao
precisa ser feita. Podem ocorrer casos de aplicaes (neste caso, problemas) que
nem mesmo com o emprego de tecnologias mais recentes seja possvel clusterizar.
As metas de desempenho desejadas (o crescimento deste) a longo prazo tambm

so uma mtrica a ser utilizada, podendo at mesmo se tornar a linha mestra para
o projeto de todo o sistema. As capacidades tem de ser bem planejadas e conhe-
cidas desde o incio do desenvolvimento do projeto, pois estas que indicaro as
possveis tecnologias a serem adotadas para se obter uma equalizao de desem-
penho e custo total de implantao. Ressalta-se que neste momento do projeto
no se pode pensar apenas nas capacidades imediatas do sistema. Deve-se tam-
bm programar o crescimento de demanda a longo prazo, picos de utilizao do
sistema, que em alguns momentos pode explodir a capacidade instalada, sistema
de recuperao de desastres, entre outras variveis.
Projeto piloto
O planejamento de um projeto ou Cluster pode ser difcil se no h conhecimento

e experincia na plataforma tecnolgica. S com a prtica e experincia que pode-
remos ser capazes de entender as capacidades e limitaes de um Cluster. Iniciar
com um projeto pequeno pode ser a melhor forma para evitar enganos e erros, e
conseqentemente, gastos excessivos.
Construir um sistema de teste com um nmero pequeno de mquinas e com base

no modelo do seu sistema, permitir determinar o que preciso antes de assumir
compromissos que podem ser equivocados. Isto provavelmente ir economizar
tempo e dinheiro, j que corrigir enganos em um Cluster de grande porte e em
produo pode ser muito demorado e principalmente ter um custo elevado.
O domnio da tecnologia tambm importante, e um projeto piloto pode ser uti-

lizado para vrias outras aplicaes, como plataforma de desenvolvimento de
sistemas, testes de configuraes, projeo de estresse de sistemas e homologa-
o de aplicaes, entre muitas outras coisas.
VERSAO 1.0 PGINA 61

Utilizao de hardware idntico
Existem excees a esta regra, mas certamente ser preciso um n frontal mais
rpido para seu sistema, da mesma maneira que tambm so necessrios discos
de maior capacidade em servidores de I/O.
No entanto, a utilizao do mesmo hardware em cada mquina do Cluster traz

muitas facilidades e simplificaes, dentre elas:
De instalao e de configurao de seus Clusters, j que poder ser usado

imagens idnticas do sistema para cada mquina.
De manuteno do Cluster, pois todos os sistemas tm a mesma configura-

o bsica. Assim, deve ser preciso manter poucas peas sobressalentes que
podero ser trocadas rapidamente, caso o hardware do equipamento apre-
sente defeitos.
Existe tambm a idia de Cluster segmentado, ou Cluster de N camadas, no qual

se teriam vrios Clusters que, trabalhando em conjunto, seriam responsveis por
toda a demanda dos sistemas que fossem executados no ambiente. Por exemplo,
uma diviso em camadas onde se tem: uma responsvel pelo armazenamento
(Cluster de armazenamento, SAN), uma pelo banco de dados, uma pela aplica-
o, uma pelo firewall e proxy; assim a modelagem do hardware para atender as
especificidades dos sistemas utilizados no ambiente de extrema importncia.
Mais detalhes deste tipo de ambiente pode ser melhor visto na sesso 3.2. Se-
guindo assim essa caracterstica de camadas de Cluster, cada uma destas tenderia
a ter um nico tipo de configurao de hardware.
Sistemas diskless
Sloan, em seu artigo [334], aconselha evitar a utilizao de sistemas que no uti-
lizam disco rgidos; no entanto, a experincia e a evoluo destes sistemas vm
mostrando que a sua eficincia pode ser muito bem aproveitada, alm de facilitar
o gerenciamento de todo o sistema de forma global. Mesmo assim, a utilizao
deste tipo de tecnologia precisa ser muito bem avaliada para verificar os prs e
contras de uma implementao baseada em tecnologia sem disco.
VERSAO 1.0 PGINA 62

A importncia da rede de comunicaes
Uma reflexo tem de ser feita antes de comear a pensar em redes: um dos gran-
des erros em projetos de Clusters, para qualquer que seja a sua finalidade, acre-
ditar que o processamento, ou alta capacidade de processamento, baseado ape-
nas em computadores, ou em seus processadores. Um Cluster precisa ser visto
como um organismo completo, onde cada pea tem sua importncia e pode ser o
responsvel por um melhor desempenho do sistema globalmente.
E exatamente nesse aspecto que a rede de comunicaes tem sua importncia

na hora de projetar o Cluster. A rede normalmente o gargalo de desempenho
para Clusters que utilizam hardware no proprietrio, ou hardware de prateleira.
Assim importante tomar cuidado e colocar a camada de rede como uma das
partes de grande importncia no projeto. A criao de camadas separadas para
dados e para gerenciamento dos sistemas, a possvel utilizao de vrias interfa-
ces de rede, ou outras tecnologias de comunicao, precisam ser avaliadas para
as caractersticas que se deseja obter. Com os baixos preos das placas Gigabit
Ethernet, a sua utilizao vem se tornando freqente nesses tipos de sistemas.
Minimize mas no subdimensione seu hardware
Ao especificar o hardware dos ns computacionais de um Cluster, h muita coisa a

ser observada. Dependendo do ambiente e do nmero de mquinas que o Cluster
ir conter, decises como utilizar ou no RACKS" sero de grande importncia,
assim como uma tendncia em ambientes de grande porte a utilizao deste
tipo de infra-estrutura para melhorar utilizao do espao fsico e facilidade de
manuteno, para pequenos ambientes ser um gasto desnecessrio.
Na especificao do hardware dos ns, certamente, no precisar de coisas como

placas de som, aceleradoras 3D, mouses, teclados e monitores. Se estiver com-
prando os equipamentos, minimizar o hardware pode baixar seu custo total de
forma a permitir comprar mais mquinas.
Mas existe um limite esta minimizao" das especificaes de hardware, cer-

tamente uma placa de vdeo ser necessria no caso de que se precise dar ma-
nuteno em alguma mquina, assim como um CD-Rom pode fazer falta para a
VERSAO 1.0 PGINA 63

instalao de softwares e do sistema operacional. Portanto, ter esses equipamen-

tos ou possibilidades de soluo para esses problemas de extrema importncia
para o ambiente, no pode ser obrigatria a necessidade de se abrir mquinas
para adicionar uma placa de vdeo ou cd-rom para resolver qualquer tipo de pro-
blema, e o custo envolvido no to grande para se evitar a aquisio destes
equipamentos.
Isole seu Cluster
No existe nenhuma razo para todos os ns do Cluster estarem visveis em sua

rede local. A existncia de uma rede separada para o Cluster tem por razo a
segurana das informaes e dos sistemas que nele so executados. Com esse
isolamento, pode-se principalmente preocupar com o desempenho do sistema,
minimizando as preocupaes com correes de seguranas. Repare que no est
sendo dito que o isolamento do Cluster evita problemas de segurana, mas sim
que muitas falhas de segurana em servidores em redes pblicas so crticos, em
um ambiente isolado e sob controle no tero as mesmas repercusses, possibili-
tando assim melhoras na disponibilidade dos sistemas.
Se for preciso obter acesso rede do Cluster, este pode ser provido atravs de co-
nexes seguras por um firewall e por uma mquina de entrada, responsvel pelo
disparo de processos no sistema. O controle de acesso e conexes ao Cluster so
temas que tm de ser bem estudados, e dependendo do tipo e principalmente do
valor desta informao, o controle tem de ser mais acurado. Nesse ponto, o con-
trole de acesso iria muito alm dos firewalls, proxies e servidores de autenticao,
mas tambm passaria pelo estabelecimento de conexes seguras e autenticadas,
com uso de certificados digitais, entre outras tecnologias.
Use ferramentas de Cluster
A utilizao de ferramentas, que automatizam as tarefas de instalao e adminis-

trao de Cluster podem ser uma soluo agradvel para os administradores de
sistemas, mas preciso dominar e entender essas ferramentas com profundidade.
VERSAO 1.0 PGINA 64

Ferramentas como o OSCAR3 , Rocks4 e XCAT5 , simplificam a instalao e o ge-

renciamento de Clusters, neste caso Cluster de processamento de alto desem-
penho. Qualquer um destes pacotes provavelmente instalar e configurar boa
parte das suas necessidades bsicas.
Assim como estes pacotes, existem outros que facilitam a utilizao de Clusters,
como o RHCS 6 que apontado para sistema de HA.
Supere o desejo pelo mais recente
Tenha como meta a ser alcanada um Cluster em funcionamento, que atenda de

melhor forma as necessidades levantadas. Sendo assim, muito improvvel que
no se precise da verso mais recente de distribuies Linux. Na maioria dos
Clusters, os usurios notaro diferenas apenas no n de entrada do sistema. Para
os ns de trabalho (ex., o tamanho do Cluster), no importa qual distribuio de
Linux est executando, contanto que execute a tarefa para a qual foi projetado.
Plano para expanso e reposio desde o princpio
O ciclo de vida de equipamentos de informtica curto, e isto fica muito evidente

quando se comea a pensar na evoluo do Cluster, de como gerenciar toda a ne-
cessidade de expanso com a viabilizao tecnolgica e tcnica necessria. Vrios
pontos tm de ser levantados, como escalabilidade, compatibilidade, custo, assim
como os motivos para a expanso.
A evoluo do Cluster para aumentar as capacidades, a escalabilidade da solu-

o utilizada tem de ser observada, para conhecer, no mnimo, quais as limitaes
da arquitetura que pretende-se implantar. Outros pontos tambm precisam ser
levantados para a expanso planejada, dentre eles: a aderncia de hardwares de
modelos diferentes, espao fsico, capacidade de refrigerao, etc. A vantagem,
3
Mais informaes podem ser vistas em http://oscar.openclustergroup.org/
4
Mais informaes podem ser vistas em http://www.rocksclusters.org/
5
Mais informaes podem ser vistas em http://www.xcat.org/
6
Mais informaes podem ser vistas em https://www.redhat.com/solutions/
clustersuite/
VERSAO 1.0 PGINA 65

no caso de expanso ou na troca de todo o Cluster, que boa parte do equipa-

mento pode ser reciclada para outras tarefas dentro do sistema.
No caso de estar trabalhando na expanso de um Cluster em funcionamento,

o estudo deste ser de grande importncia para saber como a aplicao execu-
tada no ambiente existente, fornecendo um grande volume de informao valiosa
para os novos projetos e ajustando os elementos para realizar adequadamente a
migrao.
Documente seu Cluster
Documentao bem feita e completa a chave para o aperfeioamento do uso

de seu Cluster atual e para projetos futuros. Se estiver instalando equipamentos,
mantenha o registro da informao de configurao, rede, dados histricos de
trfego, utilizao e principalmente de problemas.
Muitas vezes passamos por problemas que j foram resolvidos em ocasies ante-
riores, mas por falta de um histrico de ocorrncias, no sabemos como resolver
o problema, o que obriga a todo um retrabalho de pesquisa por solues dos
problemas apresentados. As documentaes so de extrema importncia nesses
momentos, mas as principais documentaes ainda so as relacionadas ao pr-
prio Cluster. Deve-se conhecer como as conexes de rede e energia esto feitas,
quais as configuraes e todos os detalhes tcnicos da implementao, para aju-
dar a prever problemas, bem como facilitar em muito o processo de resoluo de
qualquer incidente.
Segurana
Muitos projetos no trabalham o suficiente com a segurana dos ambientes de

uma forma integrada, ou seja, a segurana pensada tanto na interface de hardware
como na de software. A ISO 17799 Tecnologia da Informao - Cdigo de Prtica
para Gesto da Segurana de Informaes" aborda vrios aspectos da segurana
que tem de ser observados para uma boa prtica desta. Entre outros itens, ela
aborda:
VERSAO 1.0 PGINA 66

Poltica de Segurana;
Segurana Organizacional;
Segurana Relacionada ao Pessoal;
Segurana Fsica e Ambiental;
Gerenciamento de Comunicaes e Operaes;
Controle de Acesso;
Desenvolvimento e Manuteno de Sistemas, que levantam itens como:

Requisitos de Segurana nos Sistemas,
Anlise e Especificao dos Requisitos de Segurana,
Segurana em Sistemas Aplicativos,
Validao dos Dados de Entrada,
Controle do Processamento Interno,
Segurana de Arquivos do Sistema,
Controle de Software Operacional.
Gerenciamento da Continuidade do Negcio;
Obedincia a Exigncias.
Aplicao
No projeto e desenvolvimento da aplicao devem estar detalhados todos os pro-

cessos e tecnologias que sero utilizados, uma aplicao bem projetada ter su-
cesso na sua execuo em um ambiente de Cluster.
As aplicaes sero tratadas por grupos especficos: em produo no passveis

de migrao, em produo passveis de migrao, em desenvolvimento e novos
projetos.
Os tcnicos e gestores com base nos grupos acima iro montar o planejamento
para o uso das tecnologias de Cluster que considere o melhor custo/benefcio de
seu caso.
VERSAO 1.0 PGINA 67

Banco de dados
Conhecer bem as demandas de acesso aos dados pelos sistemas que sero execu-
tados no Cluster permitir uma melhor escolha da arquitetura de banco de dados
necessria para suprir as exigncias do sistema. Mais informaes podem ser
obtidas no captulo 9.
Como j observado na arquitetura de N camadas, o Cluster de banco de dados

compe a tecnologia de mais complexa deciso para uma possvel clusterizao.
VERSAO 1.0 PGINA 68

Captulo 5
Processamento Paralelo: Sua Difuso

e Uso
Um problema central em computao paralela, segundo SKILLICORN [332],

o desencontro entre as necessidades do software paralelo e as propriedades das
arquiteturas paralelas sobre as quais eles sero executados. Este distanciamento
entre o hardware e o software paralelo oscila com rapidez, isto porque o tempo
de vida de uma arquitetura paralela , via de regra, medido em anos, enquanto
que o tempo de vida desejvel para qualquer software de grande porte medido
em dcadas. Dentro de uma viso tradicional, o procedimento , no espao de
alguns anos, reescrever o software medida que uma nova tecnologia de arqui-
tetura paralela disponibilizada no mercado. A reescrita de cdigo, dentre outros
problemas, introduz custos e prazos elevados.
Isso hoje causado principalmente por causa da evoluo rpida desta rea da
computao. Apesar da rea de pesquisa j ser antiga, a sua aplicao em ambi-
entes corporativos recente e vem evoluindo muito rapidamente.
VERSAO 1.0 PGINA 69

G UIA DE C LUSTER 5.1 - A SPECTOS PARA A A DOO DO P ROCESSAMENTO PARALELO
5.1 Aspectos para a Adoo do Processamento Para-

lelo
Nesta seo sero tratados aspectos que podem ser vistos como estmulos para
adoo do processamento paralelo, seja a partir do ponto de vista da exausto das
arquiteturas seqenciais em funo dos limites impostos pela tecnologia atual,
seja considerando as necessidades dos diferentes segmentos usurios.
5.1.1 Barreiras ao Crescimento da Freqncia de Operao dos

Processadores
Como regra geral, quanto maior a freqncia de operao do processador (clock),

maior desempenho ter o computador. Porm importante ter presente que, uma
vez mantidos aspectos como conjunto de instrues, arquitetura, etc., o desempe-
nho efetivo (registrado pelos benchmarks tradicionais, tais como MIPS, MFLOPS,
SPECmarks) no ir crescer na mesma razo do clock. Outros aspectos precisa-
riam acompanhar o crescimento do clock, como por exemplo a eficincia (largura
de banda) de acesso memria. Independente desta posio no otimista para a
relao desempenho/clock, considerando o nvel em que se encontra atualmente
a velocidade de operao dos processadores, a mesma j enfrenta entraves tecno-
lgicos para seu aumento de performance.
Destacam-se os seguintes aspectos como limitadores para o crescimento do clock

(HWANG [222]): O consumo de energia e a conseqente dissipao trmica- os
componentes projetados para clocks elevados (tais como SRAM ou ECL) apresen-
tam ndices de consumo e dissipao trmica bem mais elevados que os similares
(DRAM, CMOS) para clocks mais modestos. A dimenso do processador e seus
componentes acessrios- limitados pela velocidade da luz, os eltrons podem
percorrer distncias menores medida que a durao do pulso de clock dimi-
nui. Um clock de 1 GHz (1000 MHz) limita a distncia mxima de deslocamento
dos eltrons grandeza de centmetros (o valor exato depende das caractersticas
do substrato semicondutor). Deste modo, para operar nesta velocidade se fa-
zem necessrios componentes eletrnicos altamente densos, bem como cuidados
extremos com o comprimento dos condutores que os interligam. Esta elevada
VERSAO 1.0 PGINA 70

G UIA DE C LUSTER 5.1.2 - L ARGURA DE B ANDA NO A CESSO M EMRIA
densidade de integrao e a restrio nas dimenses globais dificulta o fluxo do

elemento resfriador (ar, gua, etc.), o que, por sua vez, introduz severas dificulda-
des no processo de dissipao trmica. Alm disto, preciso considerar o fato que
em freqncias elevadas ficam potencializados os fenmenos de capacitncias e
indutncias parasitas, os quais dificultam sobremaneira os nveis de integrao
dos semicondutores.
Estes dois aspectos independentes se interrelacionam no equilbrio entre desem-

penho e possibilidade de operao estvel e confivel. As arquiteturas de alto
desempenho so utilizadas, quase sempre, em misses crticas e pelo seu custo
no usual mais do que uma unidade em cada instalao.
5.1.2 Largura de Banda no Acesso Memria
O aproveitamento do crescente poder computacional dos modernos processado-

res esbarra no de fato que o fluxo de dados possvel entre os mesmos e a memria
no cresce na mesma proporo. Este comportamento foi denominado Gargalo de
Von Neumann, e caracteriza que o poder de processamento disponibilizado para
computao de um problema limitado em funo da taxa de transferncia de
dados e instrues entre a memria e o processador.
O uso de vrios processadores na soluo do problema faculta, com a soma de

suas taxas de transferncia individuais, a superao do Gargalo de Von Neumann.
Existem diferentes formas de interligar diversas memrias a vrios processadores
na definio de uma mquina paralela.
Cada estratgia de interconexo (vide item 6.6.2) tem implicaes diretas em as-
pectos operacionais, tais como: emprego genrico (possibilidade de uso com de-
sempenho desta mquina paralela a um nmero maior de naturezas de proble-
mas), na sua escalabilidade e no seu custo, dentre outros (CULLER [128]).
VERSAO 1.0 PGINA 71

G UIA DE C LUSTER 5.1.3 - PARALELISMO I NTRNSECO DO M UNDO R EAL
5.1.3 Paralelismo Intrnseco do Mundo Real
Os fenmenos naturais so inerentemente paralelos. Deste modo, seria natural

e direto expressar as computaes pertinentes ao mundo real de forma paralela,
ou ao menos de uma forma que no impea o paralelismo. Escrever programas
seqenciais, via de regra, implica impor uma ordem as aes que so indepen-
dentes e que poderiam ser executadas concorrentemente.
Na programao seqencial, inevitvel arbitrar uma particular ordem na qual

as aes so colocadas. Isto pode tornar o computador um empecilho para a per-
cepo de novos conceitos. Some-se a isto o fato que situaes nas quais a ordem
de execuo das aes importante para o melhor entendimento do problema
real, so difceis de diferenciar daquelas nas quais a ordem de execuo pratica-
mente no importa (SKILLICORN [333]).
5.1.4 A Relao Custo-Benefcio dos Processadores de ltima

Gerao
Mesmo que a recente tendncia histrica de crescimento da velocidade dos pro-

cessadores se mantenha, a computao paralela possibilita para muitas aplica-
es uma relao custo/benefcio melhor do que a conseguida ao utilizar equipa-
mentos com um s processador de ltima gerao. Isto ocorre, em grande parte,
devido aos custos de projeto e fabricao de cada nova gerao de processadores.
A cada novo processador mais poderoso, o preo da gerao anterior cai con-
sideravelmente; deste modo, agrupar em um equipamento paralelo, processa-
dores mais antigos prov um alternativa computacional de custo competitivo.
Tendo em vista que cada nova gerao introduz um acrscimo de desempenho
com magnitude da ordem de dcimos, mesmo modestos agrupamentos de pro-
cessadores no to atuais, so viveis no que diz respeito ao desempenho global.
Este aspecto se potencializa ainda mais se a escolha tecnolgica do hardware para
interligao no apresentar custo elevado.
Esta tendncia , em parte, responsvel pela popularidade das estaes de traba-

lho em rede de alta velocidade (100 Mbps no mnimo) como alternativa de equi-
VERSAO 1.0 PGINA 72

G UIA DE C LUSTER 5.1.5 - A PLICAES E XTREMAMENTE C OMPLEXAS
pamento para processamento paralelo (CULLER [128]). E ainda mais reforada

com as quedas de preos das interfaces de comunicao Gigabit e seus compo-
nentes como switches.
5.1.5 Aplicaes Extremamente Complexas
Existem aplicaes que demandam elevadssimo poder computacional. Por mais

poderoso que possa ser determinado processador, dentro do atual estado tecno-
lgico, a combinao de vrios destes em uma arquitetura para processamento
paralelo torna disponvel maior capacidade de processamento que a possvel com
um nico processador.
Como exemplo de aplicaes que atualmente demandam grandes recursos com-

putacionais destacam-se:
inteligncia artificial, incluindo redes neurais, robtica e reconhecimento de

padres;
anlise de elementos finitos, onde aparecem diversos tipos de equaes di-

ferenciais aplicadas a mecnica esttica, eletromagnetismo, e dinmica dos
fluidos;
simulao, onde se sobressaem as tcnicas de Monte Carlo;
processamento de sinais, envolvendo FFT (Fast Fourier Transformation) sobre

grandes volumes de dados, processamento de imagens e processamento ss-
mico;
algoritmos bsicos em cincia da computao: classificao, busca e proces-

samento de rvores e grafos;
grandes bancos de dados com resposta em tempo real (OLTP On Line Tran-
saction Processing);
Freqentemente sugerido que os equipamentos paralelos, sobretudo os de

grande porte, so comprometidos com propsitos especiais. A idia inerente a
VERSAO 1.0 PGINA 73

G UIA DE C LUSTER 5.1.6 - S UPORTE T OLERNCIA A FALHAS
esta afirmao que somente um pequeno conjunto de aplicaes poderia ser exe-
cutado eficientemente em um hardware paralelo. A lista de aplicaes acima in-
dica exatamente o contrrio; a ineficincia do processamento paralelo tem muito
mais relao com as dimenses do problema" do que com as particularidades
de um domnio especfico do conhecimento humano. Nos ltimos dez anos os
computadores paralelos tem sido programados com eficincia tanto para aplica-
es do mundo comercial como para o da pesquisa e desenvolvimento (MORSE
[280]).
5.1.6 Suporte Tolerncia a Falhas
Muitas aplicaes crticas (controle de trfego areo, sistemas de controle indus-

triais, automaes bancrias, etc.) exigem um regime de operao sem interrup-
es. A existncia de redundncia de hardware, inerente s arquiteturas para-
lelas, oferece um suporte natural s tcnicas de tolerncia a falhas. Alguns pro-
cessadores podem monitorar e registrar a operao do sistema, no momento que
for detectado alguma disfuno, as partes envolvidas podem ter suas funes
continuadas por outras. Deste modo, no caso de falhas, o equipamento paralelo
pode manter a computao corrente, possivelmente ocorrendo to somente uma
diminuio no desempenho na prestao dos servios (HWANG [222]).
5.1.7 Crescimento Modular
Esta caracterstica diferencia fortemente as arquiteturas paralelas e distribudas

dos equipamentos de grande porte (mainframes) tradicionais. Nas arquiteturas
com um nico processador, o usurio no momento do crescimento da plataforma,
precisa prever sua demanda no mnimo a mdio prazo. Isto leva a um cresci-
mento feito aos saltos. Logo aps a expanso, comum a instalao como um
todo apresentar uma relao custo/benefcio ruim. Essa relao pode ser vista
na figura 5.1.7 que mostra a escalada dos custos ao longo do tempo para as duas
plataformas (alta plataforma (mainframe) e baixa plataforma (cluster e mquinas
padres de mercado)) em relao a capacidade de carga do sistema. Pode-se ver
nessa figura claramente os saltos dados, pelo excesso de capacidade de processa-
mento. O arco cinza escuro na figura 5.1.7 mostra a demanda de processamento
VERSAO 1.0 PGINA 74

G UIA DE C LUSTER 5.1.7 - C RESCIMENTO M ODULAR
ao longo do tempo, a linha vermelha mostra a linha de crescimento de custos

(C1) para o ambiente em baixa plataforma e por ltimo os degrais cinza claro
(C2) mostram o crescimento de custos para a plataforma alta.
Figura 5.1: Relao Carga X Custo de investimento, para plataforma Baixa X Alta
Tanto para o fornecedor quanto para o usurio, muito oportuno que a arqui-
tetura possa ser expandida gradualmente atravs da adio de mdulos. Esta
possibilidade permite uma melhor adequao da curva investimentos & produti-
vidade, uma vez que o equipamento poder crescer dentro de uma determinada
faixa, tendo como regulador a demanda de servio real (MORSE [280]).
VERSAO 1.0 PGINA 75

G UIA DE C LUSTER 5.1.8 - D ISPONIBILIDADE DE S OFTWARE A PLICATIVO
5.1.8 Disponibilidade de Software Aplicativo
exatamente a disponibilidade de software de terceiros com qualidade (um n-

mero tpico para as diferentes marcas seria 1500 aplicaes) que tem potenciali-
zado o mercado das estaes de trabalho de elevado desempenho. Por sua vez, a
ausncia de aplicaes disponveis no mercado tem sido um dos fatores a restrin-
gir a adoo de equipamentos paralelos por parte das empresas em geral. Poucas
empresas, exceo das instituies de pesquisa e ensino, no se intimidam ante
os esforos para portar e/ou desenvolver software para explorao do parale-
lismo. Este aspecto acaba sendo significativo no momento de decidir pela no
adoo de um equipamento paralelo. Tentando traar um perfil, possvel dizer
que no binmio fazer & comprar", o software paralelo que uma empresa poderia
necessitar, ainda est muito polarizado no fazer.
Do ponto de vista de uma empresa que desenvolve e comercializa software, a de-

ciso de investir no mercado de processamento paralelo ou em outras frentes (por
exemplo, melhoramentos em produtos j amplamente utilizados) influenciada
por alguns fatores (MORSE [280]):
pequena base instalada: o mercado de equipamentos paralelos pequeno,

independente do referencial que for utilizado. Os equipamentos maiores
esto nos laboratrios governamentais, os quais, via de regra, tem sua pr-
pria equipe de desenvolvimento. Outro grupo de equipamentos est em
universidades, utilizados principalmente para pesquisa e ensino. Por sua
vez, as empresas que fazem desenvolvimento tecnolgico de seus produtos
com o suporte de computadores paralelos (empresas qumicas, automveis,
avies), por questes de propriedade intelectual, tambm tem seu prprio
grupo de programao.
elevado custo de converso: atualmente, para uma empresa migrar seu

produto de software de uma arquitetura tradicional para uma plataforma
paralela, ter de ter uma equipe de desenvolvimento conhecedora do hard-
ware paralelo utilizado. Em funo deste hardware, podero ser necessrias
modificaes no layout de dados, no fluxo de controle, e at mesmo nos al-
goritmos bsicos utilizados. O ganho de desempenho, principal razo de
ser da adoo do hardware paralelo, poder ser prejudicado com a no ob-
servncia criteriosa destas modificaes quase sempre indispensveis.
VERSAO 1.0 PGINA 76

G UIA DE C LUSTER 5.1.9 - R ELAO ENTRE A T EORIA E A T ECNOLOGIA
validao: testar o quo correto est o porte de um software para uma m-

quina paralela pode se mostrar uma tarefa bastante complexa, at mesmo
porque os resultados das implementaes seqencial e paralela podem
apresentar diferenas. Isto se potencializa para cdigos numricos, nos
quais a convergncia, a preciso e o erro acumulado, so fortemente in-
fluenciados pelo tamanho do problema. A deciso por uma arquitetura
paralela, normalmente contempla problemas com dimenses bem maiores
que aquelas possveis de serem computadas em equipamentos com um s
processador. Apesar dos matemticos garantirem que o resultado de uma
soma de nmeros no depende da ordem de sua realizao (propriedade
associativa da soma), o hardware de ponto flutuante pode apenas se apro-
ximar desta abstrao. Consideraes similares a esta fazem da validao
do software paralelo uma atividade complexa e tratada com muita cautela
pelos desenvolvedores de software, at mesmo porque incorrees na ver-
so paralela podem lanar dvidas sobre a qualidade da verso seqencial
j disponvel.
5.1.9 Relao entre a Teoria e a Tecnologia
A teoria para o processamento paralelo foi desenvolvida aps a tecnologia e ainda

se encontra imatura em muitos aspectos. Deste modo, a teoria historicamente
no vem sugerindo caminhos ou at mesmo limites para explorao tecnolgica.
Como resultado, ainda no esto disponveis na abrangncia necessria, repre-
sentaes abstratas da computao paralela, lgicas para avaliao da mesma,
ou at mesmo algoritmos paralelos que sejam comprovadamente eficientes nas
diversas arquiteturas reais (SKILLICORN [333]).
VERSAO 1.0 PGINA 77

Parte III
Aspectos Tcnicos
VERSAO 1.0 PGINA 78

Captulo 6
Conceitos Bsicos
6.1 Arquiteturas Computacionais
A Arquitetura de computadores pode ser definida como a estrutura e a organi-

zao dos hardwares e se refere ao funcionamento interno de um computador, ou
seja, a organizao interna de todos os perifricos necessrios para a montagem
de um sistema computacional.
As arquiteturas sero caracterizadas a partir de componentes cuja nomenclatura

apresentada na figura 6.1. Estes tambm so os trs principais blocos bsicos
das arquiteturas seqenciais.
Figura 6.1: Blocos bsicos dos computadores seqenciais
VERSAO 1.0 PGINA 79

G UIA DE C LUSTER 6.1.1 - A C LASSIFICAO DE F LYNN PARA A RQUITETURAS DE C OMPUTADORES
6.1.1 A Classificao de Flynn para Arquiteturas de Computado-

res
A incluso da proposta feita por Flynn (taxonomia de Flynn) em 1966 , em pri-

meiro lugar, um compromisso com a classificao mais difundida para arquitetu-
ras de computadores.
A proposta se baseia nas combinaes possveis entre uma ou mais seqncias de

instrues, atuando sobre uma ou mais seqncias de dados. Decorre da, quatro
classes de computadores:
Seqncia de Instrues, uma Seqncia de Dados (SISD-Single Instruction

stream over a Single Data stream): corresponde aos computadores seqenciais
convencionais, nos quais s existe uma nica unidade de controle que deco-
difica seqencialmente as instrues, que operam sobre um nico conjunto
de dados.
Seqncia de Instrues, Mltiplas Seqncias de Dados (SIMD-Single Ins-

truction stream over a Multiple Data stream): corresponde aos processadores
matriciais. Nestas arquiteturas, diversos elementos processadores so ati-
vados por somente uma unidade de controle. Esta unidade est submetida
a um nico programa, cujas instrues repassam aos elementos processado-
res. Os processadores executam, concorrentemente, uma mesma instruo
sobre os dados que tm na sua memria local.
Mltiplas Seqncias de Instrues, uma Seqncia de Dados (MISD-

Multiple Instruction stream over a Single Data stream): no existem compu-
tadores construdos que se enquadrem nesta categoria.
Mltiplas Seqncias de Instrues, Mltiplas Seqncias de Dados

(MIMD-Multiple Instruction stream over a Multiple Data stream): nesta classe
se enquadram os multiprocessadores.
Arquiteturas de Memria Distribuda
Neste tipo de arquitetura, cada n tem seu processador, sua unidade de con-
trole e sua memria local (MIMD). Assim, cada n pode executar, de forma assn-
VERSAO 1.0 PGINA 80

Figura 6.2: Arquitetura genrica de multiprocessador de memria
crona, um processo independente sobre seus prprios dados (vide figura 6.2). Os
equipamentos que implementam este tipo de arquitetura tambm so conhecidos
como multicomputadores ([128], [280]).
A rede de interconexo (vide item 6.6.2) crtica para o desempenho deste tipo de
equipamento. As diversas possibilidades de implementao da rede de interco-
nexo (topologia, latncia, conteno, etc.) neste tipo de arquitetura constituem
um dos aspectos responsveis pela falta de padro no mercado de arquiteturas
paralelas.
A configurao deste tipo de arquitetura varivel. O nmero de processadores,

por exemplo, pode oscilar da casa das dezenas a alguns milhares. Em alguns
casos, o crescimento ocorre em potncias de 2 (16, 32, 64, 128, etc.) (vide item
6.6.3).
Principais aspectos positivos
Tecnologia de compilao: uma vez que cada n da arquitetura uma unidade

de processamento autnoma, possvel aproveitar toda esta tecnologia de com-
pilao disponvel para programao seqencial, agregando mesma os recursos
de uma biblioteca para troca de mensagens entre os ns processadores. So pro-
postas usuais que, utilizando desta premissa, exploram conhecidas linguagens
seqenciais como C ou FORTRAN para programao paralela.
Possibilidade de emular outras arquiteturas: resguardadas as restries ineren-

tes ao desempenho, possvel arquitetura de memria distribuda, emular ou-
tros paradigmas de controle e de organizao de memria. Uma possibilidade
usual o emprego de DSM (Distributed Shared Memory [276], [306]), atravs da
VERSAO 1.0 PGINA 81

qual o software aplicativo tem a viso de uma memria comum a todos os ns

processadores.
Compartilhamento de uso: este tipo de arquitetura permite, de forma bastante

flexvel, o particionamento e a alocao de subgrupos de processadores tare-
fas/usurios.
Principais aspectos negativos
Custo das comunicaes: em funo das caractersticas da rede de interconexo

utilizada (vide item 6.6.2), alguns algoritmos podem ter seu desempenho dimi-
nudo. Assim, o processo de planejamento, codificao e gerao de cdigo (com
a contribuio explcita ou no do programador), precisa considerar aspectos de
localidade das comunicaes e granulosidade das tarefas, para otimizar a possi-
bilidade de seu particionamento e distribuio aos processadores.
Custo de sincronizao: apesar de poderem trabalhar freqentemente de forma

assncrona, determinados momentos da execuo paralela podem exigir um es-
tado conhecido comum, para um grupo de processadores. Para minimizar o pos-
svel tempo de espera nos momentos de sincronizao, o desenvolvimento de
software deve contemplar uma distribuio de carga o mais equnime possvel (o
que nem sempre vivel), e com isso potencializar a utilizao dos processadores
e aumentar o desempenho global do processamento.
Uso ineficiente da memria: trs aspectos concorrem para a sobre-ocupao da

memria em arquiteturas de memria distribuda. O primeiro decorre da necessi-
dade de armazenamento temporrio das mensagens recebidas at que o processo
responsvel pela computao possa fazer o devido tratamento. Dependendo do
tamanho e da freqncia destas mensagens, um considervel volume de mem-
ria ter de ser destinado para isto. O segundo conseqncia da necessidade de
cpia local do cdigo executvel. O terceiro decorre, em funo da busca de de-
sempenho, de se fazer a cpia local tambm das estruturas de dados globais que
o algoritmo possa necessitar.
VERSAO 1.0 PGINA 82

Figura 6.3: Arquitetura genrica de multiprocessador de memria compartilhada
Arquiteturas de Memria Compartilhada
Neste tipo de arquitetura todos os ns tm acesso uniforme a uma nica memria

comum (vide figura 6.3). So tambm denominados de multiprocessadores sim-
tricos ([128], [280]). Uma das razes do sucesso comercial deste tipo de arquite-
tura MIMD, decorrente da sua flexibilidade de uso. Cada processador da arqui-
tetura pode ser visto como uma mquina seqencial tradicional; a existncia de
outros processadores, bem como da memria comum, pode ser abstrada. Uma
conseqncia desta caracterstica a possibilidade de utilizar o software seqen-
cial j existente, praticamente sem nenhuma modificao. Deste modo, o para-
lelismo alm de ser utilizado para melhorar o desempenho de um determinado
programa, tambm pode ser empregado para executar simultaneamente diversos
programas seqenciais do usurio.
Como a memria um recurso compartilhado, para que a mesma no se trans-

forme em um ponto de estrangulamento da operao da arquitetura, o nmero
de processadores varia, tipicamente, entre 4 e 20.
Uma estratgia para aumentar o desempenho do sistema de memria comparti-

lhada o uso de uma memria cache entre o processador e a memria comum. A
busca de um sistema eficiente para manuteno da coerncia de memria neste
tipo de arquitetura um tema complexo e originou diversos trabalhos de pes-
quisa.
A utilizao destes sistemas propica vrios aspectos positivos como:
Abstrao da localidade do processador: neste tipo de arquitetura o programa-
VERSAO 1.0 PGINA 83

dor pode abstrair a localidade do processador. Deste modo, a troca de mensagens

sincronizada por um mecanismo de escrita em variveis comuns. Como a me-
mria fisicamente compartilhada, isto pode ser feito com elevado desempenho
(via de regra maior que os obtidos com as polticas de DSM - Distributed Shared
Memory).
Semelhante s arquiteturas convencionais: os multiprocessadores de memria

compartilhada usualmente oferecem um ambiente de programao e um sistema
operacional bastante semelhante aos das mquinas seqenciais, o que facilita a
adoo da arquitetura enquanto o software est sendo adequado para uma execu-
o efetivamente paralela.
Facilidade de uso mltiplo: os processadores podem ser alocados individual-

mente ou em grupos, para diferentes programas/usurios.
Maior compartilhamento dos recursos: a memria comum facilita o comparti-

lhamento de estruturas de dados globais. Por sua vez, os recursos de entrada/-
sada e de memria virtual podem ser aproveitados por todos os ns processado-
res.
Mas tambm trs como problema da pouca escalabilidade, a poltica de acesso

uniforme memria faz com que este tipo de arquitetura, tenha como limite
um nmero de processadores em torno de 20. O constante aumento do poder
computacional dos processadores, e a conseqente necessidade destes de maior
banda-passante com a memria, contribui para potencializar este aspecto. Esta
arquitetura tambm est sujeita ao custo de sincronizao, que afeta as arquitetu-
ras de memria distribuda (vide item 6.1.1). Entretanto, como o nmero tpico
de processadores no grande, e as comunicaes tem um desempenho elevado,
a sincronizao como um todo pode ser melhor administrada.
Arquiteturas Sncronas Matriciais
Neste tipo de arquitetura, todos os processadores obedecem a uma nica uni-

dade de controle. Esta unidade busca e decodifica as instrues do programa e as
transmite para os diversos processadores que as executam, utilizando sua prpria
memria local (SIMD). Assim, a cada ciclo, todos os processadores (menos os que
VERSAO 1.0 PGINA 84

esto intencionalmente inibidos) executam sincronamente uma mesma instruo

sobre sua parte dos dados. O paralelismo se d, portanto, pela manipulao si-
multnea de diferentes partes do conjunto de dados. Da sua denominao estar
associada aos termos: arquiteturas sncronas e paralelismo de dados ([128], [280]).
Este tipo de arquitetura exige uma estrutura densa para a rede de interconexo, a
fim desta suportar a difuso das instrues a partir do controlador para a matriz
de processadores. Esta rede de interconexo tambm utilizada para distribuir
dados e recolher resultados.
O ambiente para gerao de cdigo neste tipo de arquitetura, usualmente, fica

localizado em uma estao de trabalho que atua como intermediria (front-end)
para a arquitetura. Esta estao acumula as funes de gerenciamento de con-
tas de usurio, o escalonamento das diversas requisies de processamento e o
acesso atravs da rede local de computadores.
As arquiteturas sncronas se mostram vocacionadas para algumas reas de

aplicao, nas quais oferecem uma excelente relao entre desempenho/custo.
Destacam-se as reas de processamento de sinais e imagens, nas quais a aglutina-
o de chips, cada um contendo dezenas de processadores simples e as respectivas
memrias (de pequeno tamanho), podem trazer excelentes resultados.
A Sincronizao inerente entre processadores; a natureza do modelo de controle

(nico e centralizado) garante uma operao passo-a-passo, e os processadores
esto conseqentemente sempre sincronizados.
Diferentemente do que ocorre com as arquiteturas que tm controle distribudo

(sejam de memria compartilhada ou no), estas ficam sujeitas as necessidades
eventuais de sincronizao, as quais costumam introduzir perodos de ociosidade
na operao dos processadores.
VERSAO 1.0 PGINA 85

G UIA DE C LUSTER 6.1.2 - M ULTIPROCESSADORES
Figura 6.4: Arquitetura genrica sncrona matricial
Uso eficiente da memria: a nica memria que precisa acomodar programas

a memria associada ao controlador central; as memrias dos processadores
podem ser dedicadas totalmente para dados.
Alguns aspectos negativos desta abordagem so: Escalabilidade; quando o ta-

manho da matriz de processadores cresce, podem surgir dificuldades de garan-
tir, atravs de uma rede de interconexo de grandes dimenses, a operao total-
mente sncrona dos processadores (este aspecto se potencializa com o crescimento
constante do clock dos processadores). A Ineficincia ante desvios condicionais;
os desvios condicionais dependentes de dados, precisam ser processados inde-
pendentemente, um aps o outro. Esta situao vista como um dos principais
pontos de perda de desempenho desta arquitetura. E a Dificuldade de compar-
tilhamento; uma vez que existe somente uma unidade de controle, a arquitetura
somente pode ser utilizada por um programa/usurio de cada vez. Alguns for-
necedores facultam a existncia de mais de um controlador central (com o decor-
rente acrscimo de custo), o que permitiria o compartilhamento de recursos.
6.1.2 Multiprocessadores
A arquitetura de multiprocessadores conhecida como fortemente acoplada,

uma vez que os processadores e a memria esto interligados atravs de um sis-
tema local de interconexo.
Essa arquitetura caracterizada pelo compartilhamento global de memria pelos

diversos processadores do ambiente e esse compartilhamento global de mem-
ria que se torna o gargalo da escalabilidade do ambiente. A escalabilidade em
VERSAO 1.0 PGINA 86

G UIA DE C LUSTER 6.1.3 - M ULTICOMPUTADORES
uma configurao multiprocessada varia at algumas centenas de processadores.
6.1.3 Multicomputadores
A arquitetura de multicomputadores conhecida como fracamente acoplada,

uma vez que os processadores tm suas prprias memrias locais. Essa arqui-
tetura caracterizada por ter at milhares de processadores. No h um com-
partilhamento forte, sendo as comunicaes entre os processos feitas por troca de
mensagens entre os processos que esto sendo executados nos processadores.
Um exemplo de uma configurao de multicomputadores a criao de um clus-

ter com PCs convencionais usando uma rede local ethernet. Diferente da configu-
rao de multiprocessadores em que necessrio utilizao de um comutador
especial, esse tipo de cluster utiliza peas encontradas em qualquer estabeleci-
mento de informtica.
6.1.4 Multiprocessadores Simtricos (Symmetric Multiproces-

sors - SMP)
Estes ambientes so conhecidos como arquiteturas de compartilhamento total,

so caracterizadas por at dezenas de processadores compartilhando os mesmos
recursos computacionais e rodando um nico sistema operacional. Os processa-
dores so considerados simtricos porque tm os mesmos custos para acesso
memria principal.
A utilizao de SMP mais popular do que se imagina. Eeste tipo de mquina

encontrada facilmente em grande parte das organizaes de hoje e tambm vem
ganhando espao em reas menores, reflexo da reduo de custos destes equipa-
mentos.
Um problema desta arquitetura sua escalabilidade, pois com o aumento do n-

mero de processadores a taxa de coliso de acesso memria tambm cresce,
sendo necessrio a utilizao de solues de memrias de cache e globais, que
sero vistos frente.
VERSAO 1.0 PGINA 87

G UIA DE C LUSTER 6.1.5 - CC NUMA
6.1.5 ccNUMA
Na arquitetura SMP no temos uma boa escalabilidade, pois se utiliza normal-

mente sistemas de interconexo na forma de barramento. Este tipo de inter-
conexo se torna o gargalo do sistema rapidamente. Assim outras opes de
interconexo devem ser utilizadas, como a interconexo comutada, que utiliza
comutadores (switches) como elemento de ligao entre os processadores. Tam-
bm existem outras solues de interconexo que podem aumentar a largura de
banda, mas importante deixar claro que qualquer uma destas solues agrega
alm de um custo altssimo, retardo de comunicaes entre os processadores e a
memria.
Na teoria, uma arquitetura de Acesso No-Uniforme Memria (Non-Uniform

Memory Access - NUMA) conhecida por sua capacidade de escalar at centenas
de processadores.
Mquinas NUMA preservam o modelo de programao simples de configura-

es SMP, mas com o acrscimo de tempo para acesso a memria global.
A implementao prtica de uma mquina NUMA conhecida como Acesso

No-Uniforme Memria com Coerncia de Cache (Cache Coherence Non-Uniform
Memory Access - ccNUMA), pois estas j tratam vrios problemas de acesso me-
mria desta arquitetura, como as diferenas de velocidades de acesso memrias
locais e globais, implementando sistemas de tratamento de coerncia de cache.
Aplicaes como banco de dados, ERP e CRM so aplicaes candidatas a roda-

rem nessa plataforma.
6.1.6 Processadores Massivamente Paralelos - MPP
Mquinas com configurao massivamente paralelas (Massive Parallel Processors -

MPP), so arquiteturas fracamente acopladas. Computadores que seguem este
paradigma so usualmente classificados como multicomputadores, e normal-
mente um n deste um multiprocessador.
Essa arquitetura caracterizada por milhares de ns computacionais interligados
VERSAO 1.0 PGINA 88

G UIA DE C LUSTER 6.1.7 - S ISTEMAS D ISTRIBUDOS
por uma rede de interconexo de alta velocidade. Cada n pode ser composto por
um ou mais processadores, possuindo cache e memrias locais. Cada n possui
tambm seu prprio sistema operacional, onde as aplicaes rodam localmente e
se comunicam por sistemas de trocas de mensagens (11.1).
A escalabilidade de um MPP maior do que arquiteturas de memria compar-

tilhada. Os maiores computadores classificados na lista TOP500 [364] usam este
paradigma.
Uma parte importante na configurao MPP o sistema de interconexo que liga

seus vrios ns. Entre os principais fatores em considerao na construo destes
sistemas de interconexo so, segundo DANTAS [136]:
Topologia;
Algoritmo de roteamento;
Estratgia de comutao;
Controle do fluxo entre ns.
6.1.7 Sistemas Distribudos
Os sistemas distribudos, sob o aspecto da arquitetura de mquinas, para a exe-

cuo de aplicativos, podem ser vistos como configuraes com grande poder
de escalabilidade, pela agregao dos computadores existentes nas redes con-
vencionais em um sistema nico, onde a homogeneidade ou heterogeneidade do
conjunto de mquinas, cada uma com seu prprio sistema operacional, permite
a formao de interessantes configuraes de SMPs, clusters, MPPs e grids com-
putacionais. ([136])
Vrios aspectos na utilizao de ambientes distribudos tm de ser cuidados, as-

pectos como segurana, confiabilidade, latncia da rede de comunicaes, com-
patibilidades de pacotes de softwares, entre outros.
VERSAO 1.0 PGINA 89

G UIA DE C LUSTER 6.1.8 - C LUSTERS
6.1.8 Clusters
As configuraes de clusters em termos de arquitetura computacional, podem

ser entendidas como uma agregao de computadores de forma dedicada para
a execuo de aplicaes especficas. Normalmente formados por computadores
do tipo PC, pertencentes a uma nica unidade (ex: laboratrio).
A escalabilidade um fator diferencial nestes ambientes, pois os recursos podem

crescer conforme estiverem disponveis. ([136])
6.1.9 Grids
Grids computacionais so uma nova forma de agregar ambientes geografica-

mente dispersos, com objetivos claros de especificao de qualidade de servios.
Atualmente, a Internet com uma configurao distribuda de recursos conhe-
cida como o ambiente que melhor pode demonstrar esse tipo de arquitetura. Em
outras palavras, diferentes tipos de aplicativos com diferentes tipos de requeri-
mentos de qualidade (exemplos so a largura de banda, latncia de comunicaes
e jitter1 ) so tratados de maneira igual. Em adio, os servios WEB"que ofere-
cem servios para a execuo de tarefas de usurios finais so crescentes. Desta
forma, o objetivo destas configuraes voltar toda a potencialidade de recursos
e servios disponveis para o processamento de tarefas dos usurios pertencentes
configurao de grid (DANTAS [136]). Grids computacionais so amplamente
discutidos no captulo 13 deste trabalho.
6.2 Dependabilidade
Dependabilidade um termo traduzido literalmente do ingls dependability que

rene diversos conceitos que servem de medida, tais como confiabilidade (relia-
bility), disponibilidade (availability), segurana (safety), mantenabilidade (maintai-
nability), comprometimento do desempenho (performability), e testabilidade (tes-
1
Jitter uma variao estatstica do latncia na entrega de dados em uma rede, ou seja, pode
ser definida como a medida de variao do atraso entre os pacotes sucessivos de dados
VERSAO 1.0 PGINA 90

G UIA DE C LUSTER 6.2.1 - A MEAAS
tability). Estas so as medidas usadas para quantificar a dependabilidade de um

sistema. ([304])
Assim pode-se dizer que a dependabilidade uma propriedade dos sistemas

computacionais que define a capacidade dos mesmos de prestar um servio no
qual se pode justificadamente confiar (DANTAS [136]).
Confiabilidade a medida mais usada em sistemas em que mesmo curtos pero-

dos de operao incorreta so inaceitveis. Confiabilidade uma medida proba-
bilstica que no pode ser confundida com disponibilidade. Um sistema pode ser
altamente disponvel mesmo apresentando perodos de inoperabilidade, desde
que esses perodos sejam curtos e no comprometam a qualidade do servio. Per-
formability est relacionada queda de desempenho provocada por falhas, onde
o sistema continua a operar, mas degradado em desempenho. Mantenabilidade
significa a facilidade de realizar a manuteno do sistema, ou seja, a probabi-
lidade que um sistema com defeitos seja restaurado a um estado operacional
dentro de um perodo determinado. Restaurao envolve a localizao do pro-
blema, o reparo e a colocao em operao. Finalmente, testabilidade a capaci-
dade de testar atributos internos ao sistema ou facilidade de realizar certos testes.
Quanto maior a testabilidade, melhor a mantenabilidade, por conseqncia, me-
nor o tempo de indisponibilidade do sistema devido a reparos.
A caracterizao de dependabilidade envolve ainda um conjunto de conceitos

que alguns autores dividem em trs grupos: os atributos, os meios pelos quais
ser alcanada e as ameaas. Nas prximas sesses estes trs grupos sero me-
lhores vistos.
6.2.1 Ameaas
Um defeito definido como um desvio da especificao, ou a transio de estado

do servio de um sistema de correto para um servio incorreto. Deve ser evitado
que o sistema apresente defeitos, pois estes no podem ser tolerados.
Define-se falha (ou falta) como a causa fsica ou algortmica do erro. Falhas esto
associadas ao universo fsico, erros ao universo da informao e defeitos ao uni-
verso do usurio. Assim um chip de memria, que apresenta uma falha em um
VERSAO 1.0 PGINA 91

G UIA DE C LUSTER 6.2.2 - M EIOS
de seus bits (falha no universo fsico), pode provocar uma interpretao errada
da informao armazenada em uma estrutura de dados (erro no universo da in-
formao) e como, resultado o sistema pode negar autorizao de embarque para
todos os passageiros de um vo (defeito no universo do usurio).
F ALHA = ERRO = DEF EIT O
O entendimento da relao de dependncia entre falhas, erros e defeitos a base

para o conhecimento da patologia da falha". Essa relao, como mostrado acima,
pode ser utilizada em outros componentes, no apenas fsicos, e a sua utilizao
recursiva ajuda na anlise de sistemas em diferentes nveis de abstrao. Infor-
maes mais detalhadas sobre este tpico podem ser obtidas em DANTAS [136].
6.2.2 Meios
Os meios da classificao de dependabilidade nos ajudam a trabalhar na preven-

o, tolerncia, remoo ou previso das falhas. E tem como objetivo tratar as
falhas que podem levar a erros, e que em sua propagao causam defeitos.
Preveno de Falhas
A preveno de falhas tem por objetivo aumentar a confiabilidade dos sistemas,

empregando tcnicas de controle de qualidade em projetos e desenvolvimento.
Falhas no so facilmente previsveis, ento preciso estruturar procedimentos
para que, caso ocorram, existam formas de reparo a fim de restaurar as condies
de servios. Um exemplo de falha imprevisvel a falha de um componente de
hardware.
Tolerncia Falhas
O paradigma de tolerncia falhas definido como a capacidade de um sistema

apresentar um comportamento bem definido na ocorrncia de falhas. As formas
VERSAO 1.0 PGINA 92

G UIA DE C LUSTER 6.2.2 - M EIOS
bsicas de tolerncia falhas so:
Propriedade do Sistema Operacionalidade Garantida

Operacionalidade no garantida Segurana garantida
Mascaramento Defeito seguro (fail safe)
Segurana no garantida Sem mascaramento, No tolerncia
Tabela 6.1: Formas bsicas de tolerncia falhas. Fonte DANTAS [136]
A primeira forma se caracteriza pela segurana e operacionalidade garantida,

a que realiza o mascaramento, empregado para encobrir ou ocultar falhas. Neste
item o servio apresentado pelo sistema no dever ser modificado pela ocorrn-
cia de falhas, ou seja, o sistema como um todo no dever apresentar defeito.
Logo o sistema dever permanecer operacional e em um estado seguro para os
usurios e para o meio ambiente. Esta a forma mais completa de tolerncia
falhas, a mais desejada e a de maior custo. Todas as demais formas modificam o
servio prestado pelo sistema na ocorrncia de falhas ([136]).
A tolerncia falhas consiste, basicamente, em ter hardware redundante que entra

em funcionamento automaticamente aps a deteco de falha do hardware princi-
pal.
Este texto no tem a inteno de estender demasiadamente a discusso sobre este

tema podendo ser melhor visto em DANTAS [136].
Remoo de Falhas
Uma soluo para a obteno da dependabilidade a opo conhecida como re-

moo de falhas. Esta tcnica pode ser aplicada tanto na fase de desenvolvimento
como durante o ciclo de vida do sistema. A remoo de falhas na fase de desen-
volvimento realizada atravs das etapas de verificao, diagnstico e correo.
A verificao dos mecanismos de tolerncia falhas um importante aspecto de
remoo de falhas ([136]).
VERSAO 1.0 PGINA 93

G UIA DE C LUSTER 6.2.3 - ATRIBUTOS
Previso de Falhas
A previso de falhas o ltimo meio utilizado para se alcanar a dependabili-

dade. Esta opo considera uma avaliao do comportamento do sistema com
relao ocorrncia e ativao de falhas. Esta abordagem pr-ativa pode subsi-
diar as modificaes para melhorias, tanto estruturais como para melhor eficin-
cia/eficcia dos sistemas.
6.2.3 Atributos
Os atributos de dependabilidade tm naturezas no determinsticas das circuns-

tncias dos atributos que so: Disponibilidade, Confiana, Segurana, Confiden-
ciabilidade, Integridade, Reparabilidade. Esses atributos usam medidas probabi-
lsticas para gerar seus pesos relativos. Esses pesos so medidos dependendo da
aplicao/servio considerado, assim estes pesos variam sempre, no existindo
um padro ([136]).
Disponibilidade:
Disponibilidade instantnea o atributo, definido como a probabilidade de
um sistema apresentar um servio correto, num determinado instante de
tempo t. Na anlise de disponibilidade estamos interessados no comporta-
mento de um sistema em determinados perodos de tempo, ou seja, estamos
preocupados em observar a alternncia de perodos de funcionamento cor-
reto e perodos que o sistema est de reparo. O fator importante saber
a frao de tempo na qual o sistema dever ter condies de apresentar o
servio de forma correta.
Confiabilidade:
a mtrica que avalia, o quanto um sistema pode apresentar um servio
correto continuamente durante um intervalo de tempo t, ou seja, a proba-
bilidade do sistema no apresentar defeito durante o intervalo de tempo
considerado.
Segurana:
considerada sob dois aspectos: contra catstrofes e convencional. Con-
tra catstrofes a probabilidade do sistema apresentar defeito que acarrete
VERSAO 1.0 PGINA 94

G UIA DE C LUSTER 6.3 - E SCALONAMENTO
conseqncias catastrficas para seus usurios em um intervalo de tempo.

E segurana convencional a probabilidade obtida atravs da combinao
dos atributos: disponibilidade, confidencialidade e integridade, ou seja, a
probabilidade de que no ocorra acesso ou manipulao indevida no es-
tado do sistema no intervalo de tempo.
Confidenciabilidade:
a probabilidade de no ocorrer divulgao indevida de informao no
intervalo de tempo.
Integridade:
a probabilidade de no ocorrer alteraes imprprias de estado em um
sistema no intervalo de tempo.
Reparabilidade:
Esta mtrica avalia o quanto um sistema pode ser restaurado, retornando
ao estado de servio correto em determinado tempo, dado que o mesmo
apresentou defeito.
6.3 Escalonamento
Escalonamento um processo de tomada de decises que se preocupa com a alo-

cao de recursos limitados para tarefas ao longo do tempo, e possui como meta a
otimizao de uma ou mais funes-objetivo.As tarefas podem ser operaes em
um processo de produo, execuo de software em um sistema de computao,
entre outros. As funes-objetivo tambm podem ser diversas, como a minimi-
zao do tempo mdio gasto por uma atividade de montagem de peas em uma
mquina de uma linha de produo ou a minimizao do tempo de execuo de
uma tarefa computacional.
Escalonadores de tarefas so componentes de software comumente integrados a

sistemas operacionais paralelos e/ou distribudos e que tm como funo a distri-
buio de trabalho computacional para as unidades de processamento integran-
tes do sistema, de modo a maximizar o desempenho global do processamento
realizado, isto , promover o balanceamento de carga entre as unidades de pro-
cessamento envolvidas.
VERSAO 1.0 PGINA 95

Em sistemas homogneos, o problema de balanceamento de carga pode ser redu-

zido a uma diviso de um determinado trabalho computacional em N pores
iguais e que possam ser distribudas e executadas por N unidades de proces-
samento do sistema, supostamente idnticas. Neste caso, o problema est forte-
mente relacionado maneira de como representar o trabalho computacional a ser
processado e a melhor maneira de divid-lo em vrias partes iguais.
Em sistemas heterogneos, o problema de balanceamento de carga considera-

velmente mais complexo e, nestas circunstncias, o escalonador de tarefas ganha
especial importncia. Para que o conjunto heterogneo de unidades de processa-
mento possa ser utilizado de maneira eficiente, questes como predio e moni-
toramento de desempenho, passam a integrar o problema de balanceamento de
carga.
Isso significa que um bom compromisso, entre o tempo de processamento des-

pendido na busca por uma soluo e a qualidade da soluo encontrada, deva
ser satisfeito, e no contexto deste compromisso que as principais linhas de de-
senvolvimento de escalonadores ganham forma: a dos escalonadores estticos e
a dos dinmicos.
Um importante aspecto dos escalonamentos estticos que seu clculo se faz de

maneira totalmente independente da distribuio das tarefas. O escalonamento
feito em duas etapas: na primeira etapa o clculo do escalonamento realizado,
ou seja, a atribuio das tarefas s unidades de processamento definida; no
segundo momento, um mecanismo de distribuio de tarefas deve entrar em ao
para promover a distribuio previamente calculada.
Uma importante conseqncia deste modelo de escalonamento a necessidade

de se ter informaes precisas sobre o sistema considerado. Assim, o bom funcio-
namento de um escalonamento de tarefas esttico, requer uma estimativa precisa
do desempenho do sistema em questo e a qualidade deste escalonamento um
resultado direto da preciso com que estas estimativas so obtidas. Nestas cir-
cunstncias, estimativas imperfeitas ou ocorrncias de eventos inesperados, que
afetem o desempenho do sistema durante a execuo das tarefas previamente
escalonadas, podem fazer com que seu desempenho global sofra significativos
decrscimos.
Apesar desta aparente limitao, o escalonamento esttico largamente utilizado
VERSAO 1.0 PGINA 96

em sistemas paralelos reais, uma vez que sua simplicidade de implementao lhe
confere grande robustez e facilidade de manuteno. Nestes sistemas a ocorrn-
cia de eventos que afetem significativamente o desempenho do escalonamento
rara e os resultados so freqentemente satisfatrios.
Em oposio a esta tcnica est a dos escalonadores dinmicos. O escalonamento

dinmico pode ser entendido como a aplicao de sucessivos escalonamentos es-
tticos sobre estados intermedirios de execuo da aplicao, medida que ela
executada. Os momentos em que cada um desses escalonamentos realizado
varia de escalonador para escalonador, mas o aspecto mais importante dos esca-
lonadores dinmicos, o que justifica o emprego do termo dinmico", e o fato de
o escalonamento ser feito concorrentemente distribuio e execuo das tarefas
das aplicaes.
Ao produzir-se um escalonamento com essas caractersticas, beneficia-se da habi-

lidade em lidar com grande parte das decises de escalonamento em tempo real,
o que eliminam muitos dos problemas do caso esttico. Embora as decises ainda
se baseiem em estimativas de desempenho do sistema e, conseqentemente, es-
timativas imprecisas ainda podem significar um escalonamento ineficiente. Com
isso, as conseqncias de um mau escalonamento no so to impactantes quanto
seriam no caso esttico. Assim, atrasos ou adiantamentos no tempo de concluso
de uma determinada tarefa podem ser utilizados em tempo real para o reescalo-
namento das tarefas restantes a serem executadas. Uma vantagem adicional do
fato de seu processamento ser realizado concorrentemente a execuo da aplica-
o escalonada e que isso pode significar economia de tempo global com relao
ao caso esttico.
Entretanto, os escalonadores dinmicos possuem seus inconvenientes. Em con-

trapartida aos escalonadores estticos, a implementao dos escalonadores di-
nmicos trabalhosa e requer a manipulao e gerncia de estruturas de dados
freqentemente complexas. Esse fato torna este tipo de escalonador pesado, sob o
ponto de vista da implementao e execuo, e menos robusto j que, na eventual
ocorrncia de uma falha, um grande trabalho de recuperao de estado dever ser
feito.
Outro importante aspecto no projeto de escalonadores de tarefas o paradigma

de operao adotado. A existncia de diferentes paradigmas advm do fato da
implementao do escalonador de tarefas, estar diretamente vinculado s manei-
VERSAO 1.0 PGINA 97

G UIA DE C LUSTER 6.4 - A LTA D ISPONIBILIDADE
ras de como as unidades de processamento do sistema distribudo em questo

estejam conectadas entre si, tanto fsica quanto logicamente. Assim, existe um
grande nmero de paradigmas de balanceamento de carga, emergidos de dife-
rentes topologias de interconexo, cada qual adaptado s caractersticas do am-
biente computacional no qual foi concebido.
6.4 Alta Disponibilidade
Um sistema computacional composto por diversos componentes eletrnicos

que podem falhar impedindo o acesso a informao. A crescente demanda por
sistemas que possam deixar informao disponvel para ser acessada, modifi-
cada, armazenada pelo maior tempo possvel levou fabricantes de hardware e de-
senvolvedores de software a pensarem em maneiras de como contornar esses pro-
blemas de paradas de sistemas, sejam elas causadas por falhas internas (causadas
por mal funcionamento de hardware, erros introduzidos por softwares ou outras ra-
zes de natureza imprevisvel, como interferncia magntica) ou mesmo paradas
programadas para manuteno.
O conceito de alta disponibilidade caracterizado por um sistema desenhado

para impedir perda de um servio por ele disponibilizado, reduzindo ou gerenci-
ando falhas (mais detalhes em 6.2.2) bem como minimizando tempo de desliga-
mento planejado para manuteno.
Este conceito no se resume a um software especfico, mas a um conjunto de meca-

nismos e tcnicas que tem por objetivo detectar, contornar e mascarar falhas que
venham a ocorrer ocasionando perda de acessibilidade.
senso comum na literatura caracterizar a disponibilidade pela probabilidade de

um sistema estar acessvel em determinado perodo de tempo.
A Tabela 6.4 ilustra um dos termos de comparao geralmente utilizado na ava-

liao de solues HA: nveis de disponibilidade segundo tempos de indisponi-
bilidade (downtime). Excludos desta tabela, os tempos de downtime estimados
(geralmente para manuteno ou reconfigurao dos sistemas) que so alheios s
solues e muito variveis.
VERSAO 1.0 PGINA 98

G UIA DE C LUSTER 6.5 - B ALANCEAMENTO DE C ARGA
Disponibilidade (%) Downtime/ano Downtime/ms

95 18 dias 6:00:00 1 dia 12:00:00
96 14 dias 14:24:00 1 dia 4:48:00
97 10 dias 22:48:00 0 dias 21:36:00
98 7 dias 7:12:00 0 dias 14:24:00
99 3 dias 15:36:00 0 dias 7:12:00
99,9 0 dias 8:45:35.99 0 dias 0:43:11.99
99,99 0 dias 0:52:33.60 0 dias 0:04:19.20
99,999 0 dias 0:05:15.36 0 dias 0:00:25.92
Tabela 6.2: Nveis de Alta Disponibilidade
Quanto maior a disponibilidade desejada ao sistema, maior a redundncia e custo

das solues, tudo depende do tipo de servio que se pretende disponibilizar e de
outras variveis intrnsecas ao sistema. H casos em que o custo do sistema indis-
ponvel muito maior que o custo de desenvolvimento de um ambiente de alta
disponibilidade para o mesmo. Informaes mais detalhadas sobre este assunto
podem ser obtidas na sesso 6.2 deste documento, em DANTAS [136] e softwa-
res que trabalham a disponibilidade de sistemas sero discutidos no captulo 8
tambm neste documento.
6.5 Balanceamento de Carga
Quando se projeta um sistema computacional, sabe-se a carga mdia e mxima

que este ir suportar. Apartir do momento em que a carga de utilizao do sis-
tema comea a se tornar excessiva, preciso buscar uma soluo para o aumento
de capacidade do sistema, que pode ser basicamente: i) aquisio de uma m-
quina de maior capacidade computacional, ii) melhoria de performance do sis-
tema e iii) utilizao de sistemas de balanceamento de carga.
Os sistemas de balanceamento de carga so em geral a repartio da execuo do

servio por vrias mquinas. Estas solues podem se especializar em pequenos
grupos sobre os quais se faz um balanceamento de carga: utilizao da CPU, de
armazenamento, ou de rede. Qualquer uma delas introduz o conceito de cluste-
ring, ou server farm, j que o balanceamento ser, provavelmente, feito para vrios
servidores.
VERSAO 1.0 PGINA 99

G UIA DE C LUSTER 6.6 - R EDES DE C OMUNICAES
Informaes sobre a implementao de algumas solues de balanceamento de

carga em Software Livre sero discutidos no captulo 8 deste documento.
6.6 Redes de Comunicaes
6.6.1 A Importncia da Rede de Comunicao
Em cluster a eficincia do sistema da rede de comunicao entre os ns de ex-

trema importncia e criticidade. Se a rede falha ou tem baixo desempenho, o
cluster inteiro sentir esse problema e, por conseqncia, o desempenho do sis-
tema como um todo ser atingido.
Assim comum se projetar redes para cluster pensando no apenas no desempe-

nho e latncia desta, mas tambm na alta-disponibilidade da rede.
importante considerar que uma rede um elemento bastante seguro a nvel

fsico: dificilmente uma vez instalada, a rede fisicamente ir falhar.
Outro tpico importante da rede a sua eficincia: uma rede congestionada des-
tri o desempenho do cluster. Assim, dependendo do tamanho do cluster, e da
quantidade de ns pertencentes a este, a rede poder ser a culpada diretamente
pela baixa eficincia computacional do cluster. por isto que o investimento em
uma rede tecnologicamente moderna habitual nestes tipos de sistemas.
6.6.2 Redes de Interconexo Utilizadas em Arquiteturas Parale-

las
No importando o tipo da arquitetura, todo computador paralelo necessita de

uma rede de interconexo para criar canais de comunicao entre os seus diver-
sos recursos de processamento, armazenamento e entrada/sada. Considerando
a diversidade das alternativas tecnolgicas, esta seo vai explorar aspectos cen-
trais pertinentes ao tema, a partir dos quais, podem ser entendidas as vrias al-
ternativas possveis para as redes de interconexo.
VERSAO 1.0 PGINA 100

G UIA DE C LUSTER 6.6.2 - R EDES DE I NTERCONEXO U TILIZADAS EM A RQUITETURAS PARALELAS
Alternativas para Interligar o Processador Rede de Interconexo
Do ponto de vista da organizao do hardware, existem duas possibilidades para

o posicionamento das chaves de interconexo (vide figura 6.5) apresentada por
MORSE ([280]):
chave associada ao processador: neste caso, na maioria das vezes a chave

est localizada no mesmo circuito integrado (chip) do processador. Nesta
implementao possvel para o processador enviar e/ou receber mlti-
plas mensagens concorrentes, o que em determinadas situaes pode ser
oportuno para explorao do paralelismo. Como exemplo, temos o em-
prego desta tecnologia nas arquiteturas SIMD (vide item 6.1.1) CM-1, CM-2
e AMT DAP, e tambm nas arquiteturas MIMD (vide item 6.1.1) nCube,
Transputer, iWarp e KS-1.
chave independente do processador: nesta implementao, o processador

tem um nico canal com a sua chave de interconexo. A principal vanta-
gem deste caso a maior flexibilidade para criao de ns heterogneos na
arquitetura. Os ns responsveis pela entrada/sada poderiam utilizar a
mesma chave de interconexo que os ns processadores. Embora no seja
uma prtica comum, esta segunda estratgia tambm faculta que possam
ser trocados os processadores e mantida a rede de interconexo. As arqui-
teturas SIMD no utilizam esta segunda opo de chave. Alguns exemplos
de arquiteturas MIMD que a empregam seriam o Intel Paragon, a CM-5 e
o Cray T-3D. Uma desvantagem decorrente da dissociao entre o proces-
sador e a chave de interconexo o prejuzo do nvel de integrao (mais
circuitos integrados, mais conexes, etc.).
Caractersticas que Definem o Desempenho de uma Rede de Interconexo
Alm da topologia da rede de interconexo, as outras caractersticas que se des-

tacam na definio do seu desempenho so:
largura de banda do canal: nmero de bytes por segundo que pode fluir en-
tre dois ns com conexo direta. Via de regra, a largura de banda depen-

G UIA DE C LUSTER 6.6.2 - R EDES DE I NTERCONEXO U TILIZADAS EM A RQUITETURAS PARALELAS
Figura 6.5: Alternativas para conectar o processador a rede de interconexo
dente do nmero de pulsos por segundo da arquitetura (clock) e do nmero

de bits possveis de serem enviados por pulso.
latncia de comutao: tempo inerente operao da chave de comuta-

o. Se dois processadores precisam trocar dados, e no existe um canal
interligando os dois diretamente, as chaves de comutao intermedirias
precisam propagar a mensagem atravs da rede de interconexo. As la-
tncias elevadas trazem prejuzo ao desempenho da arquitetura paralela,
sobretudo quando a mensagem necessita passar por diversas chaves.
independncia de processador: caracteriza a necessidade de o processador

ser ou no interrompido, para auxiliar na atividade de comunicao. Mui-
tas das atuais implementaes de redes de interconexo permitem que o
processador continue sua computao enquanto uma mensagem est sendo
transmitida, recebida ou roteada. Isto minimiza o custo introduzido pela
necessidade de comunicao entre processadores.
conteno: pode ocorrer a recepo praticamente simultnea de duas men-

sagens por uma determinada chave, e ambas podem necessitar usar o
mesmo canal de sada. Uma obrigatoriamente ter de aguardar. O atraso na
computao do processador que aguarda a mensagem retida pode resultar
em perda de desempenho. Uma possibilidade o hardware de comutao
prever uma poltica de tempo compartilhado para as portas das chaves; isto
dividiria o custo de espera entre os dois processadores destinatrios, porm

G UIA DE C LUSTER 6.6.3 - T OPOLOGIAS DA R EDE DE I NTERCONEXO
introduziria custos de comutao (vide latncia de comutao).
6.6.3 Topologias da Rede de Interconexo
A interconexo direta de todos os processadores, entre si, no vivel quando o

nmero dos mesmos aumenta. Como regra geral utilizado um padro para defi-
nir as ligaes. Este padro denominado de topologia da rede de interconexes.
Trs parmetros podem ser utilizados para caracterizar o possvel desempenho
de uma topologia. Os mesmos so: a largura da bisseo, o dimetro e o grau
(BAKER [71]).
A largura da bisseo indica quantas mensagens simultneas podem ser troca-

das entre duas metades da rede de interconexo. um indicador da largura de
banda possvel para as comunicaes atravs da rede. O dimetro indica qual o
menor nmero de ns intermedirios que precisam ser envolvidos, para que dois
processadores, o mais distantes possvel, se comuniquem.
O grau indica o nmero mximo de mensagens que podem ser manipuladas (en-
viadas ou recebidas) simultaneamente por cada um dos processadores.
Topologia em Barramento
Nesta topologia, todos os processadores esto conectados em um nico barra-

mento compartilhado. Quando um processador necessita comunicar-se com ou-
tro, ele aguarda que o barramento esteja livre e propaga no mesmo a mensagem;
o destinatrio, por sua vez, identifica que a mensagem para si e a recebe (vide
figura 6.6).
No caso de duas transmisses simultneas, o software detector de colises inter-

rompe as transmisses e os processadores voltam a tentar novamente aps um
perodo de tempo determinado aleatoriamente.
Assim sendo, a sua largura da bisseo 1. Isto significa que esta topologia
no permite mais do que um par de processadores em comunicao simultanea-
mente.

Figura 6.6: Topologia em barramento
Do ponto de vista do desempenho, esta topologia somente vivel para um pe-

queno nmero de processadores e/ou classes de problemas cujos algoritmos im-
plementem pouca comunicao. Esta topologia bastante usual em pequenos
agrupamentos (clusters) de estaes de trabalho interligadas por redes locais.
Topologia em Malha
Os processadores nesta topologia tem um canal de comunicao direto com o seu

vizinho (a). Uma variao que utilizada consiste em interligar as extremidades
da grade, criando uma configurao denominada malha toroidal (b), a qual reduz
o dimetro da malha por um fator de 2 (vide figura 6.7).

A largura da bisseo de uma malha N onde N o nmero de processadores.
A largura da bisseo dobra para a malha toroidal. O dimetro da topologia em

malha 2( N 1), e o seu grau fixo e de valor 4.
Figura 6.7: Topologia em malha
O hardware para este tipo de tecnologia de simples construo e expanso. A

malha se adapta bem a algoritmos utilizados em clculos cientficos, onde se des-
taca a manipulao de matrizes.
Uma arquitetura que utiliza esta topologia o Intel Paragon.

Topologia em Hipercubo
Toda rede de interconexo hipercbica est alicerada sobre uma estrutura multi-
dimensional baseada em endereos binrios.
Os tamanhos do hipercubo so definidos por potncias de 2; N=2D onde D a

dimenso do hipercubo e N o nmero de processadores.
Em funo disto, todos os ns podem ser identificados por um nmero binrio.

Cada n conectado a todos os seus vizinhos; isto faz com que o hipercubo tenha
grau varivel e de valor D (vide figura 6.8).
Figura 6.8: Topologia em hipercubo
A topologia hipercbica confere boas propriedades rede de interconexo; a lar-

gura da bisseo N/2, e o dimetro log2 N . Apesar de apresentar bom desem-
penho para muitos padres de comunicao, sua eficincia se mostra bastante
dependente do algoritmo de roteamento a ser empregado.
Um aspecto inconveniente do hipercubo sua escalabilidade, o nmero de pro-

cessadores sempre cresce em potncia de 2. Alm disso, como o grau de cada n
em funo do tamanho do cubo, toda expanso no nmero de processadores
implica em adicionar mais um canal de comunicao a todos os ns. Para cubos
maiores, estas caractersticas podem trazer inconvenientes para a administrao
do custo/benefcio quando da expanso da arquitetura. Um equipamento que
emprega esta topologia o Ncube 2.

G UIA DE C LUSTER 6.6.4 - D ISPOSITIVOS DE INTERCONEXO
Topologia em rvore
A clssica rvore binria, com processadores nas suas folhas, tem se mostrado
uma boa opo de topologia para arquiteturas paralelas. O dimetro de uma r-
vore completa 2log2 ((N+1)/2), bastante similar ao do hipercubo (N o nmero
de processadores). A largura da bisseo, por sua vez, somente 1, o que pode
introduzir um severo gargalo quando processadores de uma metade da rvore
precisarem se comunicar com os da outra metade.
A soluo para pequenssima largura da bisseo da rvore utilizar uma vari-

ante denominada rvore larga. Em uma rvore larga (vide figura 6.9), a largura
dos ramos (canal) cresce a medida em que se sobe das folhas em direo raiz.
Figura 6.9: Topologia em rvore
A largura da bisseo da rvore larga plena N e o seu dimetro proporcional a

2(logN ). A arquitetura da CM-5 da Thinking Machines utiliza uma verso modifi-
cada da rvore larga.
6.6.4 Dispositivos de interconexo
J esto disponveis comercialmente dispositivos de interconexo que propiciam

a criao de ambientes similares a multicomputadores ou multiprocessadores,
utilizando computadores convencionais.
Existem atualmente duas grandes classes de dispositivos de interconexo para

alto desempenho. Uma primeira classe formada por dispositivos cuja soluo
baseada em programao por troca de mensagens entre processadores no nvel de

placa de rede, esta soluo permite a criao de multicomputadores. Exemplos

de equipamentos desta classe so: Myrinet, Gigabyte System Network e Giganet,
sistemas que utilizam rede Gigabit ethernet tambm so encontrados, mas com
desempenho de rede mais baixo. No se pode confundir as tecnologias Gigabit
ethernet, Gigabyte System Network e Giganet. A Gigabit ethernet a mais conhecida,
utilizada e de menor custo, todavia o seu desempenho muito menor comparado
com as outras solues.
A segunda classe formada por interconexes e tem como peculiaridade uma

soluo que cria a abstrao de uma memria virtual nica (multiprocessador)
entre todos os computadores interligados no dispositivo. Exemplo desta so o
Quadrics Network (QSNET) e Dolphin SCI.
Gigabit Ethernet
O padro Gigabit Ethernet uma extenso dos padres 10 Mbps Ethernet e 100
Mbps Fast Ethernet para interconexo em redes. Esse padro surgiu da necessi-
dade criada pelo aumento da largura de banda nas "pontas"das redes (ex.: servi-
dores e estaes de trabalho) e tambm pela reduo constante dos custos entre
as tecnologias compartilhadas e comutadas, juntamente com as demandas das
aplicaes atuais.
O padro Gigabit Ethernet tem como principais vantagens a popularidade da tec-

nologia Ethernet e o seu baixo custo. Trata-se de uma tecnologia padro, prote-
gendo o investimento feito em recursos humanos e em equipamentos. No h ne-
nhuma nova camada de protocolo para ser estudada, conseqentemente, h uma
pequena curva de tempo de aprendizagem em relao atualizao dos profis-
sionais. Graas s vantagens trazidas por essa tecnologia, ela tornou-se tambm
outra possibilidade para a interconexo em clusters.
Apesar da alta velocidade, o padro Gigabit Ethernet no garante o fornecimento

de QoS (Qualidade de Servio), que um dos pontos mais fortes da tecnologia
ATM. Desta forma, ele no pode garantir o cumprimento das exigncias de apli-
caes, como a videoconferncia com grande nmero de participantes, ou mesmo
uma transmisso de vdeo em tempo-real de um ponto para muitos outros.

Myrinet
Myrinet um tipo de rede baseada na tecnologia usada para comunicao e troca

de pacotes entre processadores trabalhando em paralelo. Myrinet implementa
auto-inicializao, baixa latncia e switches cut-through". As interfaces de host
mapeiam redes, selecionam rotas, controlam o trfico de pacotes e transformam
endereos de rede em rotas. Seu software otimizado permite que seja feita uma
comunicao direta entre os processos do usurio e a rede. Uma diferena em
relao s LANs est nas altssimas taxas de transmisso e nas baixssimas taxas
de erro, alm de controle de fluxo em todos os links.
Um link Myrinet um par full-duplex de canais Myrinet opostos. Um canal Myrinet

unidirecional e ele o meio de comunicao que carrega caracteres de informa-
es. O fluxo do remetente pode ser bloqueado, temporariamente, pelo receptor
a qualquer hora, durante ou entre pacotes, usando controle de fluxo.
Num ambiente de comunicao confivel pode-se empregar roteamento cut-

through", no qual no existe a bufferizao do pacote inteiro com checagem de
erro no checksum".
No roteamento store-and-forward", se o canal de sada est ocupado ele fica en-

fileirado num circuito de roteamento ou n, que supostamente tem memria su-
ficiente para bufferizar o pacote. J no roteamento cut-through"os circuitos de
roteamento podem bloquear com controle de fluxo se o canal de sada no estiver
disponvel. Desta forma o circuito de roteamento cut-through"no requer buffe-
rizao, pois cada link pode prover seu prprio controle de fluxo. Para prover o
controle de fluxo, as redes MPP reconhecem cada unidade de fluxo de controle,
tipicamente um byte.
InfiniBand
InfiniBand uma arquitetura que define um barramento de computador serial de

alta velocidade, projetado tanto para conexes internas quanto externas. Ele
o resultado da combinao de duas tecnologias concorrentes, Future I/O, desen-
volvida pela Compaq, IBM e Hewlett-Packard com a Next Generation I/O (ngio),
desenvolvido por Intel, Microsoft, Dell, Hitachi, Siemens e Sun Microsystems.

Em agosto de 1999, os sete lderes da indstria, Compaq, Dell, Hewlett-Packard,

IBM, Intel, Microsoft e Sun Microsystems formaram a IBTA (InfiniBand Trade As-
sociation). A primeira especificao da arquitetura InfiniBand foi feita em junho de
2001.
A arquitetura InfiniBand surgiu devido necessidade de se melhorar o desempe-

nho dos dispositivos de E/S e das comunicaes, que surgiu juntamente com o
aumento da capacidade de processamento dos processadores.
InfiniBand uma arquitetura ponto-a-ponto que se destina a fornecer aos cen-

tros de dados uma conectividade para entradas/sadas melhoradas e adaptadas
a qualquer tipo de trfego. Uma conexo InfiniBand substituir os vrios cabos
atuais e servir simultaneamente para a conectividade do cluster (proprietria),
da rede (em vez do Gigabit Ethernet) e do armazenamento (em vez da atual Fibre
Channel). uma tecnologia comutada que utiliza trs tipos de dispositivos, co-
mutadores, interfaces HCA (Host Channel Adapter), que so os conectores usados
na comunicao interprocessadores do lado dos servidores e nas interfaces TCA
(Target Channel Adapter), que so tipicamente usadas para conexo nos subsiste-
mas de E/S.
A tecnologia InfiniBand utiliza uma estrutura hierrquica, com comunicao do

tipo ponto-a-ponto. Nessa abordagem, todo n pode ser o iniciador de um canal
para qualquer outro. Ainda possvel que vrios dispositivos de E/S peam
dados simultaneamente ao processador.
As duas principais vantagens do InfiniBand so a baixa latncia e alta largura de

banda. A baixa latncia beneficia principalmente as aplicaes sensveis latn-
cia, com comunicao entre processos (IPC) e sistemas gerenciadores de bancos
de dados (DMBS). A alta largura de banda beneficia principalmente as aplicaes
que necessitam grande largura de banda, como armazenamento, web, compu-
tao de alto desempenho, e outras aplicaes especializadas, como edio de
vdeo.
Devido a suas caractersticas, InfiniBand uma tecnologia adequada para aplica-

es de HPC (High Performance Computing). Enquanto InfiniBand prov muitas
caractersticas avanadas que servem para um grande leque de aplicaes, con-
tudo esta tecnologia ainda um padro em evoluo e deve sofrer muitas melho-
rias. Algumas das melhorias planejadas para InfiniBand incluem especificaes

de maiores taxas de sinalizao, controle de congestionamento e qualidade de

servio (QoS).
Gigabyte System Network
GSN um padro ANSI (American National Standards Institute) de tecnologia de

rede que foi desenvolvida para redes de alta performance enquanto mantm com-
patibilidade com tecnologias de rede como HIPPI, Ethernet, e outros padres de
rede. GSN tem uma alta capacidade de banda (800MB por segundo) e baixa la-
tncia.
Caractersticas:
Capacidade de Banda: acima de 800MB por segundo em full-duplex. Ve-

locidade comparvel com Fibre Channel, ATM OC12, Gigabit Ethernet, and
HIPPI;
Latncia: latncia de 4 microseconds; latncia do MPI de 13 microseconds;
Interoperabilidade: IP sob GSN, ST sob GSN, BDS sob GSN e ARP sob GSN;
Biblioteca para diversos S.O.
Mais informaes podem ser obtidas no endereo: http://hsi.web.cern.ch/

HSI/gsn/gsnhome.htm
Quadrics Network (QSNET)
Quadrics Network, tambm conhecida como QSNET, consiste de dois blocos. Um

chamado de ELAN", que representa uma interface de rede programvel, e ou-
tro chamado de ELITE" que caracterizado pelo switch de alto desempenho
e baixa latncia. Os dispositivos ELITE so interligados em forma de topologia
Flat-Tree", alcanando a possibilidade de interligao da ordem de milhares de
dispositivos de comutao.

G UIA DE C LUSTER 6.7 - P ROTOCOLOS DE C OMUNICAO
Scalable Coherent Interface (SCI)
SCI um padro recente de comunicao utilizado na interligao de componen-

tes de um cluster. A abordagem cria um sistema de compartilhamento de mem-
ria global, atravs de um sistema de coerncia de cache, baseado em diretrios
distribudos.
6.7 Protocolos de Comunicao
6.7.1 Frame Relay
O Frame Relay uma eficiente tecnologia de comunicao de dados, usada para

transmitir de maneira rpida e barata a informao digital atravs de uma rede de
dados, dividindo essas informaes em frames (quadros) ou packets (pacotes) a um
ou muitos destinos. Em 2006, a Internet baseada em ATM e IP nativo comearam,
lentamente, a impelir o desuso do frame relay.
6.7.2 Asynchronous Transfer Mode
ATM um protocolo de redes de computadores para comunicao de alto nvel

que encapsula os dados em pacotes de tamanho fixo (53 bytes; 48 bytes de dados
e 5 de cabealho), em oposio aos de tamanho varivel, comuns nas redes de
comutao de pacotes (como os protocolos IP e Ethernet). No ATM, esses pacotes
so denominados clulas. O protocolo VPI (Virtual Path Identifier) que utili-
zado neste tipo de tecnologia de rede, possui 8 bits na interface UNI e 12 bits na
interface NNI. A tecnologia ATM permite a transmisso de dados, voz e vdeo.
O ATM uma tecnologia de comunicao ou mais especificamente, de comutao

rpida de pacotes que suporta taxas de transferncia de dados com variao de
velocidades sub-T1 (menos de 1,544 Mbps) at 10 Gbps. Como outros servios de
comutao de pacotes (Frame Relay, SMDS), ATM atinge as suas altas velocidades,
em parte, pela transmisso de dados em clulas de tamanho fixo, e dispensando
protocolos de correo de erros.

G UIA DE C LUSTER 6.7.3 - FDDI
6.7.3 FDDI
O padro FDDI (Fiber Distributed Data Interface) foi estabelecido pelo ANSI (Ame-
rican National Standards Institute) em 1987. Este abrange o nvel fsico e de ligao
de dados (as primeiras duas camadas do modelo OSI).
A expanso de redes de mbito mais alargado, designadamente redes do tipo

MAN (Metropolitan Area Network), so algumas das possibilidades do FDDI, tal
como pode servir de base interligao de redes locais, como nas redes de cam-
pus.
As redes FDDI adotam uma tecnologia de transmisso idntica s das redes To-
ken Ring, mas utilizando, comumente, cabos de fibra ptica, o que lhes concede
capacidades de transmisso muito elevadas (na casa dos 100 Mbps ou mais) e a
oportunidade de se alargarem a distncias de at 100 Km.
Estas particularidades tornam esse padro bastante indicado para a interligao

de redes atravs de um backbone. Nesse caso, o backbone deste tipo de redes
justamente o cabo de fibra ptica duplo, com configurao em anel FDDI, ao qual
se ligam as sub-redes.
6.7.4 Modelo OSI
OSI (Open Systems Interconnection), ou Interconexo de Sistemas Abertos, um

conjunto de padres ISO relativo comunicao de dados. Um sistema aberto
um sistema que no depende de uma arquitetura especfica.
O modelo tem como propsito facilitar o processo de padronizao e obter inter-

conectividade entre mquinas de diferentes sistemas operativos, a Organizao
Internacional de Padronizao (ISO - International Organization for Standardization)
aprovou, no incio dos anos 80, um modelo de referncia para permitir a comuni-
cao entre mquinas heterogneas, denominado OSI (Open Systems Interconnec-
tion). Esse modelo serve de base para qualquer tipo de rede, seja de curta, mdia
ou longa distncia.

G UIA DE C LUSTER 6.7.5 - P ROTOCOLO IP
6.7.5 Protocolo IP
IP um acrnimo para a expresso inglesa "Internet Protocol"(ou Protocolo de

Internet), que um protocolo usado entre duas mquinas em rede para encami-
nhamento dos dados.
Os dados numa rede IP, so enviados em blocos referidos como pacotes ou data-
gramas (os termos so basicamente sinnimos no IP, sendo usados para os dados
em diferentes locais nas camadas IP). Em particular, no IP nenhuma definio
necessria antes do host tentar enviar pacotes para um host com o qual no comu-
nicou previamente.
O IP oferece um servio de datagramas no confivel (tambm chamado de me-

lhor esforo); ou seja, o pacote vem quase sem garantias. O pacote pode chegar
desordenado (comparado com outros pacotes enviados entre os mesmos hosts),
tambm podem chegar duplicados, ou podem ser perdidos por inteiro. Se a apli-
cao precisa de confiabilidade, esta adicionada na camada de transporte.
O IP o elemento comum encontrado na Internet dos dias de hoje. descrito no

RFC 791 da IETF, que foi pela primeira vez publicado em Setembro de 1981.
6.7.6 Transmission Control Protocol
O TCP (acrnimo para o ingls Transmission Control Protocol) um dos protocolos

sob os quais assenta o ncleo da Internet nos dias de hoje. A versatilidade e ro-
bustez deste protocolo tornou-o adequado para redes globais, j que este verifica
se os dados so enviados pela rede de forma correta, na seqncia apropriada e
sem erros, pela rede.
O TCP um protocolo do nvel da camada de transporte (camada 4) do Modelo

OSI e sobre o qual assentam a maioria das aplicaes cibernticas, como o SSH,
FTP, HTTP, portanto, a World Wide Web.

G UIA DE C LUSTER 6.7.7 - User Datagram Protocol
6.7.7 User Datagram Protocol
O UDP um acrnimo do termo ingls User Datagram Protocol que significa pro-
tocolo de datagramas de utilizador (ou usurio). O UDP faz a entrega de mensa-
gens independentes, designadas por datagramas, entre aplicaes ou processos,
em sistemas host. A entrega no confivel", porque os datagramas podem ser
entregues fora de ordem ou at perdidos. A integridade dos dados pode ser ge-
rida por um checksum"(um campo no cabealho de checagem por soma).
6.7.8 Real-time Transport Protocol
RTP (do ingls Real Time Protocol) um protocolo de redes utilizado em aplicaes
de tempo real como, por exemplo, Voz sobre IP, que a entrega de dados udio
ponto-a-ponto. Define como deve ser feita a fragmentao do fluxo de dados-
udio, adicionando a cada fragmento informao de seqncia e de tempo de
entrega. O controle realizado pelo RTCP - Real Time Control Protocol. Ambos
utilizam o UDP como protocolo de transporte, o qual no oferece qualquer ga-
rantia que os pacotes sero entregues num determinado intervalo. Os protocolos
RTP/RTCP so definidos pela RFC 3550 do IETF (Internet Engineering Task Force).
6.7.9 Virtual Router Redundancy Protocol
O VRRP designado para eliminar pontos de falhas criados por default-gateway

de rede LAN (Local Area Network).
VRRP um protocolo especificado pela IEFT2 (RFC 3768) que permite dois ou
mais roteadores atuarem como um roteador virtual. De acordo com essa especifi-
cao, os roteadores se apresentam para cliente com um endereo IP virtual (VIP
- Virtual IP) correspondente a um MAC virtual (VMAC), mas cada qual possui
seu prprio IP e MAC reais. Se o roteador primrio (master), que inicialmente
possua os dados virtuais, falhar ento um roteador secundrio (backup) assume
a tarefa de roteamento.
2
Internet Engineering Task Force

G UIA DE C LUSTER 6.7.9 - Virtual Router Redundancy Protocol
As trocas de mensagem, para verificao de estado entre os servidores, acontecem

atravs de IP multicast. Uma falha no recebimento dessas mensagens em um in-
tervalo especifico de tempo leva a um processo de eleio de um novo master. Em
situao normal, apenas o master envia mensagens (IP multicast), apenas quando
h escolha para novo master que os servidores de backup enviam mensagens.
. Virtual Router Roteador virtual, abstrao formada por um ou mais roteadores

rodando VRRP.
. VRRP Instance Implementao em programa do protocolo VRRP rodando em

um roteador.
. Virtual Router ID (VRID) Identificao numrica para um Virtual Router em

particular que deve ser nico para cada segmento de rede.
. Virtual Router IP Endereo IP associado ao um VRID que usado por clientes

para obter servios dele. gerenciado pela instncia do VRRP que possui o
VRID.
. Virtual MAC address Em casos em que endereo MAC usado (Ethernet), este
endereo MAC virtual associado ao Endereo IP virtual.
. Priority Valor (que varia de 1 a 254) associado a cada roteador rodando VRRP
como maneira de determinar o master (quanto maior o nmero, maior priori-
dade).
Figura 6.10: Esquema de funcionamento de um sistema VRRP

G UIA DE C LUSTER 6.7.9 - Virtual Router Redundancy Protocol
Na figura 6.10, o servidor A envia pacotes multicast para outras instncias do

VRRP que rodem na rede (no caso, apenas o roteador B). Estes pacotes carregam
informao para duas finalidades principais:
. Forar a eleio de outro master caso haja algum com maior prioridade.
. Notificar instncias VRRP de backup que h um master ativo, caso no exista

comunicao em intervalo definido, haver uma nova escolha de master.

Captulo 7
Cluster de Armazenamento
7.1 Introduo
O aumento da capacidade de processamento e a maior utilizao de sistemas in-

formatizados para automatizar e auxiliar a execuo dos mais variados processos
e sistemas de informao, ocasionou um acmulo de informaes e de dados que
necessitam ser armazenados e consolidados.
Conjuntamente com este aumento na demanda de armazenamento dos dados, a

capacidade e as tecnologias de armazenamento evoluram expressivamente nos
ltimos anos, chegando recentemente a alcanar PetaBytes1 .
No ambiente corporativo so utilizadas diversas mdias e tecnologias para ar-

mazenamento de dados, de uma maneira geral podem ser classificadas em dois
grandes grupos:
Tecnologias de Armazenamento Online - Encontram-se nesta categoria as

tecnologias de armazenamento normalmente utilizadas por aplicaes ou
sistemas que demandam o acesso online aos dados. Alguns exemplos de
tecnologias que encontram-se neste grupo so: Disco Rgido, Storage De-
vices, Sistemas de arquivos distribudos, Sistemas de Arquivos Paralelos,
Dispositivos Raid, Controladoras de Discos, entre outras.
1
1P etaByte = 1.073.741.824M egaByte

G UIA DE C LUSTER 7.2 - Block Devices
Tecnologias de Armazenamento Offline - Encontram-se neste grupo as tec-

nologias de armazenamento normalmente utilizadas para armazenar dados
de backup ou dados que no precisam ser acessados online. Alguns exem-
plos de tecnologias que encontram-se neste grupo so: Fitas, CD, DVD, dis-
positivos de fitas, bibliotecas de fitas.
Em sistemas crticos normalmente so utilizados dispositivos de armazenamento

proprietrios denominados "Storage Devices"e/ou "Bibliotecas de Fita"que pos-
suem capacidade de armazenar Terabytes de informaes, com funcionalidades
que permitem consolidar e manter a integridade dos dados em um ambiente cen-
tralizado.
Existem alternativas tecnolgicas de Cluster e Grid baseadas em padres abertos

de hardware e software para a implementao da camada de armazenamento e
consolidao de dados em sistemas crticos.
Estas tecnologias em Cluster e Grid para armazenamento podem ser divididas

em 3 categorias:
Tecnologias baseadas em dispositivos de Blocos
Sistemas de Arquivos Distribudos
Sistemas de Arquivos Paralelos
Sendo abordadas as principais tecnologias neste captulo.
7.2 Block Devices
A definio bsica de dispositivos de blocos :
Bloco especial de arquivo ou dispositivo de blocos so usados para corresponder

a dispositivos pelos quais os dados so transmitidos na forma de blocos. Estes
ns de dispositivo so freqentemente usados para dispositivos de comunicaes
paralelos como discos rgidos e drives de CD-ROM."[390]

G UIA DE C LUSTER 7.2.1 - A RRANJO R EDUNDANTE DE D ISCOS - RAID
A diferena mais significante entre dispositivos de blocos e dispositivos de ca-

rter, que os dispositivos de blocos tem rotinas de buffer para os controles de
entrada e sada. O sistema operacional aloca um buffer de dados para prender
cada bloco simples para a entrada e sada. Quando um programa envia um pe-
dido de dados para ser lido , ou escrito, no dispositivo, cada carter de dados
armazenado no buffer apropriado. Quando o buffer est cheio e um bloco com-
pleto alcanado, a operao apropriada executada e o buffer limpo."[390]
Os Dispositivos de Blocos so a parte de sustentao dos sistemas de arquivos

dos sistemas operacionais. Sendo sua manipulao um processo bsico para ex-
plorao de dispositivos de armazenamento.
Existem vrias implementaes de Dispositivos de Blocos com a inteno de se-

rem utilizados em ambientes de Cluster. Neste captulo sero apresentados os
mais conhecidos.
7.2.1 Arranjo Redundante de Discos - RAID
O Arranjo redundante de discos (Redundant Array of Independent Disks -

RAID), um sistema que usa mltiplos discos rgidos para compartilhar ou re-
plicar dados entre esses discos. Dependendo da verso escolhida, o benefcio do
RAID um ou mais vezes o incremento da integridade de dados, de tolerncia
falhas, de desempenho ou de aumento de capacidade de armazenamento de
dados, comparado com um simples disco.
Em suas implementaes originais, sua vantagem chave era a habilidade de com-

binar mltiplos dispositivos de baixo custo usando uma tecnologia mais antiga
em uma disposio que oferecesse uma grande capacidade de armazenamento,
confiabilidade, velocidade, ou uma combinao destas. Num nvel bem mais
simples, RAID combina mltiplos discos rgidos em uma nica unidade lgica.
Assim, em vez do sistema operacional ver diversos discos rgidos diferentes, ele
v somente um disco rgido. O RAID usado tipicamente em servidores, e geral-
mente, mas no necessariamente, implementado com discos rgidos de tama-
nhos idnticos.
Com as diminuies dos preos de discos rgidos e com a disponibilidade em

G UIA DE C LUSTER 7.2.2 - RAID VIA H ARDWARE E VIA S OFTWARE
larga escala de RAID em chipsets de placas-me, RAID vem se tornando uma

opo para computadores de usurios mais avanados, assim como na criao de
grandes sistemas de armazenamento de dados.
Usurios avanados vem usando RAID em suas estaes de trabalho e Workstati-

ons para aplicaes que necessitam de utilizao intensiva de disco, seja de leitu-
ra/escrita ou mesmo capacidade de armazenamento, como no caso de aplicaes
de edio de vdeo e udio.
7.2.2 RAID via Hardware e via Software
RAID pode ser implementado por hardware, na forma de controladoras especiais

de disco, ou por software, como um mdulo do kernel que fica dividido entre a
controladora de disco de baixo nvel e o sistema de arquivos acima dele.
RAID via hardware um controlador de disco, isto , um dispositivo fsico que

pode atravs de cabos conectar os discos. Geralmente ele vem na forma de
uma placa adaptadora que pode ser plugada" em um slot ISA/EISA/PCI/S-
Bus/MicroChannel. Entretanto, algumas controladoras RAID vm na forma de
uma caixa que conectada atravs de um cabo entre o sistema controlador de
disco e os dispositivos de disco.
RAIDs pequenos podem ser ajustados nos espaos para disco do prprio compu-
tador; outros maiores podem ser colocados em um gabinete de armazenamento,
com seu prprio espao, para disco e suprimento de energia. O hardware mais
novo de RAID usado com a mais recente e rpida CPU ir provavelmente forne-
cer o melhor desempenho total, porm com um preo expressivo. Isto porque a
maioria das controladoras RAID vem com processadores especializados na placa
e memria cache, que pode eliminar uma quantidade de processamento consi-
dervel da CPU. As controladoras RAID tambm podem fornecer altas taxas de
transferncia atravs do cache da controladora.
RAID via hardware geralmente no compatvel entre diferentes tipos, fabrican-

tes e modelos: se uma controladora RAID falhar, melhor que ela seja trocada por
outra controladora do mesmo tipo. Para uma controladora de RAID via hardware
poder ser usada no Linux ela precisa contar com utilitrios de configurao e ge-

G UIA DE C LUSTER 7.2.3 - Distributed Replicated Block Device - DRBD
renciamento, feitos para este sistema operacional e fornecidos pelo fabricante da

controladora.
RAID via software uma configurao de mdulos do kernel, juntamente com

utilitrios de administrao que implementam RAID puramente por software, e
no requer um hardware especializado. Pode ser utilizado o sistema de arquivos
ext2, ext3, DOS-FAT, etc.
Este tipo de RAID implementado atravs dos mdulos MD do kernel do Linux

e das ferramentas relacionadas.
RAID por software, por sua natureza, tende a ser muito mais flexvel que uma
soluo por hardware. O problema que ele em geral requer mais ciclos e capaci-
dade da CPU para funcionar bem, quando comparado a um sistema de hardware,
mas tambm oferece uma importante e distinta caracterstica: opera sobre qual-
quer dispositivo do bloco podendo ser um disco inteiro (por exemplo, /dev/sda),
uma partio qualquer (por exemplo, /dev/hdb1), um dispositivo de loopback (por
exemplo, /dev/loop0) ou qualquer outro dispositivo de bloco compatvel, para criar
um nico dispositivo RAID. Isso diverge da maioria das solues de RAID via
hardware, onde cada grupo unifica unidades de disco inteiras em um arranjo.
Comparando as duas solues, o RAID via hardware transparente para o sistema

operacional, e isto tende a simplificar o gerenciamento. J o via software, tem mais
opes e escolhas de configuraes, fazendo sua manipulao mais complexa.
7.2.3 Distributed Replicated Block Device - DRBD
Projeto:DRBD
Stio Oficial:http://www.drbd.org
Licena:GPL
Responsvel: LinBit - http://www.linbit.com
DRBD um acrnimo para o nome ingls Distributed Replicated Block Device. O

DRBD consiste num mdulo para o kernel de Linux, juntamente com alguns
scripts e programas, que oferecem um dispositivo de blocos projetado para dispo-

nibilizar dispositivos de armazenamento distribudos, geralmente utilizado em

clusters de alta disponibilidade. Isto feito espelhando conjuntos de blocos via
rede (dedicada). O DRBD funciona, portanto, como um sistema RAID baseado
em rede.
Como Funciona
A figura 7.1 mostra a viso do nvel conceitual de funcionamento do DRBD -

Trata-se de um driver intermedirio entre o block device virtual (/dev/drbd*), o
block device real local (/dev/[sh]d*) e os block devices remotos. Todas as transfe-
rncias so efetuadas pelo protocolo TCP/IP, o que permite sua implementao
at mesmo em mquinas geograficamente afastadas.
Cada dispositivo envolvido (tratados localmente como parties) tem um estado,

que pode ser primrio ou secundrio. O DRBD cria, em todos os ns, um vnculo
entre um dispositivo virtual (/dev/drbdX) e uma partio local, inacessvel di-
retamente. Toda a escrita realizada no servidor primrio, que ir transferir os
dados para o dispositivo de bloco do nvel mais baixo (a partio) e propag-los
para os restantes servidores, de estado secundrio. O secundrio simplesmente
escreve os dados no dispositivo de bloco do nvel mais baixo. As leituras so
sempre realizadas localmente.
Se o servidor primrio falhar, o DRBD mudar o dispositivo secundrio para pri-

mrio e as transferncias passaro a ocorrer no sentido oposto. Note que o DRBD
no trabalha no nvel do sistema de arquivos, mas sim ao nvel de blocos do disco
rgido. Nos sistemas de arquivos que no disponibilizam journaling, dever ser
realizada aps transio primrio-secundrio uma verificao da consistncia
do sistema de arquivos; em Linux, significa executar o fsck.
Para evitar a execuo da verificao da consistncia do sistema de arquivos, um

processo altamente custoso, recomenda-se a utilizao de sistemas de arquivos
que possuam journaling.
Se o servidor que falhou retornar, o DRBD, mediante as configuraes, devolver

- ou no - o estado de primrio ao servidor original, aps uma sincronizao.
Em caso negativo, o chamado modo legacy, o servidor que detm o estado de

Figura 7.1: Viso do nvel conceitual de funcionamento do DRBD.
primrio ir conserv-lo at o servio ser encerrado nessa mquina.
Apesar do DRBD possuir o seu prprio modo de determinar qual dos servidores
dever ser primrio, a sincronizao com o sistema genrico no trivial. Para re-
duzir estas dificuldades e a necessidade de interao do usurio,freqentemente
utilizado um sistema gerenciador de cluster, como o heartbeat, para tratar das
transies de estado. Alm desta transio de estados, o sistema ser responsvel
por montar o sistema de arquivos na nova mquina que se tornou primria.
Caractersticas
Nota-se, no entanto, que:

Figura 7.2: Fluxo de intercomunicao entre as camadas dos dispositivos Linux - repare que o
DRBD no tem como notificar o mdulo do sistema de arquivos - mas o oposto ocorre.
Se as parties no forem do mesmo tamanho, o dispositivo DRBD ir auto-

maticamente assumir-se como sendo do tamanho mnimo entre as parties
envolvidas - o que permite alguma flexibilidade relativamente aos discos
disponveis em cada n.
Apenas um dos ns pode ter acesso de leitura e escrita (ReadWrite,

R/W)[KROVICH], e ser designado como DRBD/Primary. O(s) restante(s)
n(s) ser/sero designado(s) como DRBD/Secondary. Embora o n
DRBD/Secondary possa montar o dispositivo (apenas) em modo ReadOnly
(R/O), praticamente intil, dado que as atualizaes ocorrem apenas num
sentido (do Primary para o Secondary) e a camada que gere block devices no
dispe de nenhuma forma de notificar alteraes na camada que gere o sis-
tema de arquivos embutido.
Situao do projeto
A maioria dos clusters HA (HP,Compaq,...) atualmente utilizam dispositivos de

armazenamento compartilhados; estes dispositivos, altamente dispendiosos, per-
mitem que sejam conectados simultaneamente mais de um servidor, em geral
atravs do barramento SCSI compartilhado ou Fiber Channel.
O DRBD usa a mesma semntica de um dispositivo compartilhado, mas no ne-

G UIA DE C LUSTER 7.2.4 - Global Network Block Device - GNBD
cessita de nenhum hardware especfico. Ele trabalha no topo de redes IP, que so
de implementao generalizada e de baixo custo, comparativamente aos sistemas
dedicados de armazenamento (como Storage Area Networks - SAN).
Atualmente o DRBD garante acesso de leitura-escrita apenas num servidor de

cada vez, o que suficiente para a implementao de sistemas fail-over tpico de
um cluster HA. Existe uma verso de desenvolvimento 0.8 que garante acesso de
leitura-escrita para dois servidores, entretanto esta verso ainda no est estvel
suficiente para ser utilizada em ambientes de produo. As possibilidades de
aplicao sero mltiplas, como para servidores web ou banco de dados de larga
escala, onde operam sistemas de arquivos como o GFS, ou OCFS2, por exemplo.
Para se utilizar a verso de desenvolvimento do drbd(0.8), no modo

Primrio/Primrio necessrio utilizar um sistema de arquivos compartilhado
como por exemplo os citados acima. Somente um sistema de arquivos compar-
tilhado capaz de gerenciar o lock de acesso de maneira global ao sistema de
arquivos, garantindo a integridade dos dados. No se deve ser utilizado siste-
mas de arquivos comuns, tais como: xfs, ext3, reiserfs, neste modo de operao
do drbd.
7.2.4 Global Network Block Device - GNBD
Projeto: Global Network Block Device

Stio Oficial: http://sources.redhat.com/cluster/gnbd/
Licena: GPL
Responsvel(eis): Red Hat
GNBD (Global Network Block Devices) [230] um dispositivo que prov o acesso no
nvel de blocos a dispositivos de armazenamento remotos em uma rede TCP/IP.
O GNBD composto por um mdulo no kernel e um conjunto de utilitrios de
sistema, possuindo uma parte servidora, que responsvel por exportar o disco
via rede, e uma parte cliente, que responsvel por mapear localmente um disco
remoto.
A parte servidora do GNBD capaz de exportar qualquer dispositivo de blocos,

G UIA DE C LUSTER 7.2.4 - Global Network Block Device - GNBD
alguns exemplos de dispositivos de blocos so: Disco Rgidos Ide ou SCSI, Pen-
drive, Volumes lgicos, DRBD, dispositivos armazenados em storage devices.
Normalmente um servidor GNBD exporta um dispositivo de blocos local para

um n GFS[230]. Este dispositivo exportado em rede pode ser acessado local-
mente e remotamente por vrios servidores simultaneamente, entretanto para
manter a integridade dos dados necessrio utilizar um sistema de arquivos
compartilhado, como por exemplo GFS ou OCFS2.
Tambm possvel agregar diversos dispositivos gnbd em um ou mais volumes

lgicos LVM, utilizando a tecnologia de clusterizao de volumes lgicos desen-
volvida pela Red Hat, CLVM. Atravs da utilizao do GNBD e CLVM possvel
criar uma estrutura de SAN2 para armazenamento de arquivos em um cluster ou
rede de servidores.
O gargalo de performance para configuraes com um grande nmero de cli-

entes, geralmente, encontra-se na conectividade de rede, pois o GNBD utiliza
uma nica thread para cada instncia cliente-servidor-dispositivo, desta forma,
quanto mais clientes melhor ser a performance do servidor gnbd (em termos de
throughput total). Obviamente, a performance por cliente ir diminuir, por conta
da limitao da largura de banda. Outro fator de performance num ambiente que
utilize gnbd a performance do disco local no servidor, se esta performance for
baixa, ela no ser ampliada com a utilizao do GNBD. Desta forma recomen-
dado sempre fazer uma anlise da performance dos discos locais e da rede para
manter um equilbrio e tentar conseguir a maior performance possvel.
importante salientar que o GNBD no um dispositivo de blocos distribudo

ou replicado, de forma que os os dados no so replicados ou distribudos entre
dois ou mais servidores.
A figura 7.3 apresenta um exemplo de cenrio gnbd onde o dispositivo de blocos

local do servidor gnbd exportado via rede TCP/IP para 3 clientes gnbd que
mapeiam este disco localmente.
2
Storage Area Network

G UIA DE C LUSTER 7.2.5 - I NTERNET SCSI - I SCSI
Figura 7.3: Exemplo de cenrio GNBD
7.2.5 Internet SCSI - iSCSI
O Internet SCSI (iSCSI) [385] um protocolo de rede padro, oficialmente rati-

ficado em 11/02/2003 pelo IETF(Internet Engineering Task Force), que permite o
uso do protocolo SCSI sobre redes TCP/IP. O iSCSI um protocolo de camada de
transporte nas especificaes do framework SCSI-3. Outros protocolos de camada
de transporte incluem a interface SCSI paralela e Fiber Channel.
A Aceitao do iSCSI em ambientes de produo corporativos foi acelerada pela

grande utilizao de gigabit ethernet nos dias de hoje. A construo de uma
Storage Area Newtork (SAN) baseada em iSCSI se tornou mais barato, alm de
uma alternativa vivel a utilizao de SANs baseadas em Fiber Channel.
O protocolo iSCSI utiliza TCP/IP para sua transferncia de dados. Diferente de

outros protocolos de armazenamento em rede, como por exemplo Fiber Channel,
para o seu funcionamento ele requer somente uma simples interface Ethernet ou
qualquer outra interface de rede capaz de suportar TCP/IP. Este fato permite a
centralizao do armazenamento com baixo custo, sem o nus e os problemas

de incompatibilidade naturalmente associados a utilizao de Fiber Channel em

SANs.
Algumas pessoas crticas do protocolo iSCSI esperam uma performance pior que
a existente no Fiber Channel, isto ocorre por conta do overhead adicionado pelo
protocolo TCP/IP na comunicao entre cliente e dispositivo de armazenamento.
Entretanto, novas tcnicas, como por exemplo TCP Offload Engine (TOE3 ) ajudam
a reduzir este overhead. De fato, com a performance disponvel nos servidores
modernos, uma interface de rede padro com um driver eficiente pode superar a
performance de uma placa TOE porque menos interrupes e menos transfern-
cias de memria DMA so necessrias. As solues iniciais de iSCSI so baseadas
em uma camada de software. O Mercado iSCSI est crescendo rapidamente e deve
melhorar em performance e usabilidade quanto mais organizaes implementa-
rem redes gigabit e 10 gigabit, e fabricantes integrarem suporte ao protocolo iSCSI
nos seus sistemas operacionais, produtos SAN e subsistemas de armazenamento.
iSCSI se torna cada vez mais interessante pois as redes ethernet esto comeando
a suportar velocidades maiores que o Fiber Channel.
Dispositivos de Armazenamento
No contexto do armazenamento em computadores, o iSCSI permite que um iSCSI
initiator conecte a dispositivos iSCSI target remotos tais como discos e fita em
uma rede do IP para I/O ao nvel de bloco (block level I/O). Do ponto da vista dos
drivers de sistema operacional e de aplicaes de software, os dispositivos apa-
recem como dispositivos locais SCSI. Ambientes mais complexos, que consistem
de mltiplos Hosts e/ou dispositivos, so chamados de rea de Armazenamento
em Rede (Storage Area Networks - SAN).
Os dispositivos de iSCSI no devem ser confundidos com os dispositivos

Network-Attached Storage (NAS) que incluem softwares de servidor para o con-
trole de requisies de acessos simultneos de vrios Hosts. Permitir que ml-
tiplos Hosts tenham acesso simultneo a um simples dispositivo uma tarefa
comumente difcil para todos os dispositivos SCSI. Sem uma comunicao entre
os hosts, cada um dos hosts no possui conhecimento do estado e inteno dos
outros hosts. Esta condio ocasiona corrupo de dados e race conditions. Para
realizar esta tarefa atravs da utilizao do iSCSI necessrio utilizar um sistema
de arquivos compartilhado como por exemplo o GFS e o OCFS2.
3
http://en.wikipedia.org/wiki/TCP_Offload_Engine

iSCSI Conceitos e Viso Funcional
O protocolo iSCSI responsvel pela execuo de comandos SCSI entre dois dis-
positivos em uma rede TCP/IP. Comandos SCSI so executados atravs de cha-
madas iSCSI e os status SCSI so retornados como respostas.
Os termos Initiator e Targets referem-se iSCSI initiator node" e iSCSI target

node" respectivamente.
De acordo com protocolos similares, o Initiator e Targets dividem suas comunica-

es em mensagens. O termo iSCSI protocol data unit (iSCSI PDU) usado para
designar essas mensagens.
Por razes de performance, iSCSI permite phase-collapse. Atravs de um comando

os seus dados associados, podem ser enviados em conjunto do Initiator para o
Targets e os dados e respostas podem ser respondidos em conjunto pelos Targets.
O sentido de transferncia do iSCSI definido com respeito ao Initiator. Os limites

de sada ou a sada de dados so transferidos do Initiator para o Targets, enquanto
que o limite de entrada de dados ou os dados entrantes so transferncias do
Targets para o Initiator.
Implementaes do Initiator, no Linux.
Linux Initiators:
Core-iSCSI - Baseado em partes GPL do comercial PyX initiator http://

www.kernel.org/pub/linux/utils/storage/iscsi.
Intel-iSCSI (Intel) - Prova de conceito do iSCSI intiator e target da Intel para

Linux http://intel-iscsi.sf.net/.
Open-iSCSI - Nova implementao do initiator para Kernel 2.6.11 e superi-

ores http://www.open-iscsi.org/.
UNH-iSCSI - Initiator e target implementado pela University of New

Hampshire.

G UIA DE C LUSTER 7.3 - S ISTEMAS DE A RQUIVOS D ISTRIBUDOS
Informaes mais detalhadas sobre iSCSI podem ser obtidas nas RFCs: RFC-3720
http://www.ietf.org/rfc/rfc3720.txt e RFC-3783 http://www.ietf.org/
rfc/rfc3783.txt
7.3 Sistemas de Arquivos Distribudos
Os Sistemas de Arquivos Distribudos (SADs) se destacam pelo acesso remoto aos

dados de forma transparente para os usurios. Nas sees a seguir, realizamos
uma resenha sobre alguns deles, comeando com aqueles que deram incio a toda
pesquisa na rea. importante deixar claro que a maior parte dessa resenha foi
baseada nos textos ([245], [246]).
7.3.1 Conceitos Bsicos
Nesta sesso encontram-se alguns conceitos e servios disponibilizados pelos sis-

temas de arquivos distribudos e paralelos, assim como algumas de suas caracte-
rsticas, qualidades e solues ([192], [351]) que os pesquisadores e desenvolve-
dores da rea tentam prover.
Nomes e Localizao
A maioria dos arquivos armazenados em um sistema de arquivos possui um

nome e um caminho, que o identifica unicamente em tal sistema. Um caminho re-
presenta um n de uma estrutura de diretrios, que pode ser representada como
uma rvore (veja fig. 7.4).
Tal rvore possui somente uma raiz. Cada n pode possuir rvores ou arquivos.
Dessa forma, para localizar um arquivo em uma rvore de diretrios (usados para
agrupar arquivos) basta seguir o caminho do arquivo e, ao chegar no diretrio
final, procurar pelo nome de tal arquivo. A forma como esse nome e esse caminho
so definidos depende muito do sistema operacional. Por exemplo, no Unix um

G UIA DE C LUSTER 7.3.1 - C ONCEITOS B SICOS
Figura 7.4: Exemplo de uma rvore de diretrios
caminho definido como uma seqncia de nomes de diretrios, todos separados

pelo caractere /. O ultimo nome dessa seqncia pode ser o nome do arquivo
ou de um diretrio.
Em sistemas distribudos, possvel encontrar o nome da mquina, em que o

arquivo se encontra, dentro dessa definio de caminho. Porm procura-se deixar
isso transparente para o usurio.
Cache
Para melhorar o desempenho no acesso aos arquivos de um sistema, procura-se

guardar informaes muito acessadas em memria, para evitar a sobrecarga de
se ter que obt-las novamente do meio fsico onde esto armazenadas.
Isso ajuda muito na economia de tempo de processamento pois para acessar da-
dos remotos, por exemplo, o sistema est limitado velocidade da rede, que,
mesmo rpida, estar limitada velocidade do meio fsico de armazenamento
do servidor remoto, pois este ainda precisaria procurar os dados, carreg-los na
memria e envi-los para o cliente.
Mesmo no acesso a dados locais, a velocidade de acesso memria muito maior

que a velocidade de acesso ao meio de armazenamento, por exemplo, um disco
rgido, que precisaria mover o brao de leitura at a trilha em que se encontram

G UIA DE C LUSTER 7.3.1 - C ONCEITOS B SICOS
os dados e esperar at que a rotao do disco traga-os a cabea de leitura.
Em sistemas de arquivos distribudos, pode-se ter caches tanto no cliente como

no servidor, evitando assim que o cliente acesse muito a rede para obter os dados
do servidor, enquanto que o servidor diminui o acesso ao meio fsico de armaze-
namento dos dados para envi-los ao cliente.
O uso de cache uma boa soluo para o problema de desempenho no acesso aos
arquivos, porm existem problemas como o de sincronizao dos dados do cache
com os dados do meio fsico. Assim, se algum outro cliente alterar os dados no
servidor, este precisa avisar a todos os clientes que seus caches podem estar com
uma verso antiga dos dados.
Alm disso, o tamanho do cache reduzido, o que gera a necessidade de um

algoritmo para saber quais dados devem permanecer no cache e quais podem
ser removidos para dar lugar a novos dados. O ideal, segundo [351], remover
somente os dados que no sero mais acessados. Como no possvel prever isso,
foram estudadas vrias tcnicas e algoritmos para que o resultado final chegue
o mais prximo disso. O algoritmo LRU (Least Recently Used), segundo [351],
o que melhor se aproxima do timo e, talvez por isso, o mais usado nesse tipo
de situao. Assim, sempre que um novo dado acessado, este incorporado
ao cache. Se o cache estiver cheio, so removidos os dados que foram acessados
h mais tempo, para dar lugar aos dados que esto vindo. Porm, se os dados
retirados do cache tiverem sido alterados, estes devem ser enviados de volta ao
servidor ou ao disco para serem gravados. Naturalmente, conforme o padro de
uso pode ser mais interessante usar outras polticas de substituio.
Transparncias para o Usurio
Alguns sistemas de arquivos distribudos (SADs) implementam caractersticas

que o tornam transparentes para o usurio, que no precisa saber detalhes sobre
o sistema de arquivos. Algumas dessas transparncias so [192]:
Nome: O nome do recurso a ser utilizado (como um arquivo ou diretrio)

no deve indicar ou conter indcios de onde este est localizado;

G UIA DE C LUSTER 7.3.2 - S ERVIOS O FERECIDOS PELOS SAD S
Localizao: O usurio no precisa fornecer a localizao fsica do recurso

para encontr-lo;
Acesso: O usurio no perceber se o arquivo que est sendo usado local

ou remoto. Essa a filosofia usada no sistema de arquivos virtual (VFS) do
Solaris e do Linux;
Replicao: Os arquivos do SAD podem ter cpias armazenadas em lo-

cais diferentes. O usurio no deve perceber que existem vrias cpias do
mesmo arquivo. Para ele s ser apresentada uma, e quem a escolher o
SAD;
Concorrncia ou Paralelismo: Vrios usurios podem acessar o mesmo ar-

quivo ao mesmo tempo, mas isso no deve ser perceptvel para esses usu-
rios;
Falha: O SAD deve garantir que o acesso aos arquivos seja ininterrupto e
sem falhas, sem que o usurio saiba como isso tratado.
7.3.2 Servios Oferecidos pelos SADs
Para proporcionar um ambiente simples e fcil de usar, escondendo toda a com-

plexidade por trs dos engenhosos algoritmos e idias desenvolvidas pelos pes-
quisadores em sistemas de arquivos, existem vrios servios oferecidos pelos
SADs. Muitos deles acabaram se tornando essenciais e so adotados em vrios
sistemas. Alm disso, por ser muito comum encontr-los, vrios possuem uma
interface comum independente da implementao, para ajudar o desenvolvedor
das aplicaes que iro usar tais SADs.
Servio de Nomes Distribudo
O servio de nomes se preocupa em indicar a localizao de um determinado

arquivo, dado o seu nome ou caminho. Se a localizao do arquivo estiver arma-
zenada no nome dele, como por exemplo jaca:/tmp/teste, ento esse servio
de nomes no prov transparncia de localizao. Para prover essa transparn-
cia, o nome ou caminho de um arquivo no deve ter indcios de sua localizao
fsica.

Caso esse arquivo mude de lugar, ou tenha vrias cpias, o seu nome ou cami-
nho no precisar ser alterado para ser encontrado. Para isso, o servio precisa
oferecer ou resoluo por nomes, ou resoluo por localizao, ou ambos.
Resoluo por nomes mapeia nomes de arquivos legveis por humanos para no-
mes de arquivos compreensveis por computadores, que normalmente so nme-
ros, facilmente manipulveis pelas mquinas. Por exemplo, o endereo http:
//www.example.com mapeado para o IP 192.0.34.166. Atravs desse conjunto
de nmeros possvel encontrar uma mquina na rede Internet, utilizando-se de
tabelas de rotas de endereos mascarados que indicam como chegar a posio
desejada.
Resoluo por localizao mapeia nomes globais para uma determinada localiza-
o. Por exemplo, nmeros de telefone possuem cdigo do pas, da localidade,
etc. Se transparncia por nome e por localizao estiverem sendo utilizadas si-
multaneamente, pode ser muito difcil realizar um roteamento para determinar a
localizao de um determinado nome. Solues com servidores centralizados ou
distribudos so opes, porm os centralizados podem se tornar um gargalo, en-
quanto os distribudos precisam usar alguma tcnica de descentralizao, como
por exemplo cada servidor responsvel por um determinado subconjunto de
arquivos, ou cada um resolveria a localizao de determinados tipos de arquivos.
Servio de Arquivos Distribudo
O servio de arquivos responsvel por fornecer operaes sobre os arquivos

que compem o sistema, que podem ser armazenados de diferentes formas, de-
pendendo do seu tipo e uso. Por exemplo, arquivos que compem um banco de
dados podem ser armazenados em formato de registros, arquivos que so usados
por aplicaes multimdia costumam ser armazenados em formato contnuo no
disco, para agilizar sua leitura, etc.
Esse servio tambm cuida das propriedades dos arquivos, como data de criao,
data de alterao, tamanho, dono do arquivo, permisses de leitura, escrita e
execuo, alm de qualquer outra informao relevante. Tais informaes so
chamadas tambm de meta-dados.

Tambm responsabilidade desse servio manter a integridade das operaes re-

alizadas nos arquivos. Por exemplo, quando uma aplicao altera algum arquivo,
todas as demais aplicaes que estiverem acessando-o devem perceber essa alte-
rao o mais rpido possvel.
Existem dois tipos de implementao de servio de arquivos: acesso remoto e

cpia remota, que podem ser com ou sem estado. No caso do acesso remoto, o
cliente no possui um espao para guardar os arquivos que estiver usando e toda
e qualquer operao realizada com os arquivos ser sempre atravs da rede. Isso
pode deixar o sistema muito lento, j que depende da velocidade da rede.
J no caso da cpia remota, o cliente recebe uma cpia do arquivo para trabalhar
e, quando tiver terminado, devolve as alteraes para o servidor. Isso s funci-
ona se o cliente tiver espao suficiente para armazenar o arquivo. A velocidade
da rede s influenciar durante as transmisses do arquivo de um local a outro
e a implementao s ser considerada muito eficiente caso o arquivo seja total-
mente alterado. Porm, se o cliente s se interessar por um determinado trecho
do arquivo, recursos de transmisso estaro sendo gastos sem necessidade. Da
existe uma variante dessa implementao onde somente os blocos que se quer
trabalhar so enviados para o cliente, chamada de cache de bloco.
possvel tambm que esse servio lide com replicao de arquivos, que ajuda
no acesso concorrente, dando maior velocidade para as aplicaes dos clientes,
ajudando-o tambm a deixar os arquivos sempre disponveis, caso algum servi-
dor fique fora do ar.
Servio de Diretrios Distribudo
Esse servio responsvel por manter a organizao dos arquivos armazenados

no sistema. Ele fornece uma interface para que os usurios possam arranjar seus
arquivos de forma hierrquica, que estruturada em diretrios e subdiretrios.
Na maioria dos casos, um subdiretrio s tem um nico pai.
O servio precisa manter uma lista de todos os diretrios ativos, junto com seus
respectivos arquivos. Ele precisa ter a capacidade de identificar e remover arqui-
vos que no estejam em diretrio algum, como por exemplo quando um diretrio

removido. No caso em que so permitidos mltiplos pais, essa tarefa no to

fcil, pois os arquivos ou subdiretrios ainda podem estar sendo referenciados
por outros diretrios ou recursos. Para resolver esse problema, colocado um
contador de referncias para arquivos e diretrios, que se chegar a zero significa
que o arquivo ou diretrio no possui nenhum outro recurso (como hard links,
subdiretrios, etc.) apontando para ele, podendo ento ser removido. Note que,
geralmente, os links simblicos no influenciam nesse contador. Exemplificando,
a figura 7.5 mostra uma estrutura de diretrios distribuda em dois servidores. Se
for requisitada a remoo da ligao AE (um hard link ), ou da ligao B E, ou
da ligao C E (um link simblico), somente a ligao pedida ser removida.
Porm, somente as duas primeiras alteram o contador do diretrio E, indicando
quantas referncias apontam para ele. Assim, se forem removidas as ligaes
A E e B E esse contador chegar a zero e os ns E, F e G sero removi-
dos. No caso, o diretrio F est em um servidor diferente do diretrio raiz a ser
removido, mas o servio de diretrios deve cuidar disto.
Figura 7.5: Estrutura de diretrios distribuda
Algumas das operaes sobre diretrios oferecidas pelos servios de diretrios

so criao, remoo, alterao, listagem, alterao de permisses. Alm delas,
o servio tambm influncia no gerenciamento de arquivos, como nas operaes
de criao, remoo, mudana de nome, busca, duplicao, entre outras.

G UIA DE C LUSTER 7.3.3 - A LGUMAS C ARACTERSTICAS D ESEJADAS EM SAD S
7.3.3 Algumas Caractersticas Desejadas em SADs
Qual sistema de arquivos deve-se usar em um sistema distribudo? Para resolver

essa dvida, primeiramente analisa-se qual o tipo de aplicao que ser utilizada
e, a partir disso, tenta-se descobrir o que mais importante para ela, como to-
lerncia a falhas, acesso concorrente, ou alguma outra caracterstica. Algumas
dessas caractersticas ([192], [246]) so descritas nessa sesso.
Disponibilidade
Depender de um servio da rede que saiu do ar por questes de falta de ener-

gia eltrica, manuteno ou falha do hardware algo inconveniente, ainda mais
quando ocorre perda dos dados.
Dessa forma, existem vrios estudos para evitar que os servios deixem de ser
oferecidos, seja qual for o motivo.
Se um servidor cair, ficar fora do ar ou da rede, o sistema de arquivos no pode

perder informaes e nem ficar inacessvel total ou parcialmente. Alm disso, o
usurio no precisa saber como isso foi implementado. Ele simplesmente requi-
sita um arquivo e o sistema de arquivos deve entreg-lo, mesmo que algum dos
servidores esteja fora do ar. O arquivo no pode ficar indisponvel e isso deve ser
totalmente transparente ao usurio. Isso se chama transparncia a falhas.
muito comum sistemas ficarem indisponveis no por falha do prprio servi-

dor, mas por falha na rede de comunicaes. Caso um cliente deseje acessar um
arquivo que est em um servidor inacessvel naquele momento, o sistema opera-
cional do cliente costuma travar o processo que o pediu at que o servidor volte
a ficar acessvel.
Uma das solues para se resolver esse problema a replicao dos dados, ou
seja, o mesmo arquivo, ou parte dele, deve estar em diferentes servidores. As-
sim, caso algum servidor fique fora da rede, outro fornecer os mesmos arquivos.
Alguns sistemas de arquivos distribudos foram criados levando esse conceito s
ultimas consequncias, como o caso do CODA, detalhado na sesso 7.3.6.

Escalabilidade
Os sistemas distribudos so, em geral, projetados e configurados pensando-se

na configurao da rede naquele momento. Porm essa rede pode aumentar,
ou seja, dezenas ou centenas de novos ns podem ser adquiridos e conectados
nesse sistema. A menos que se tenha considerado essa situao no momento do
projeto da rede, dificilmente um sistema de arquivos distribudo apresentar bom
desempenho para servir a todos os clientes aps esse crescimento [246].
Vrios problemas podem ocorrer, dentre eles, a inutilizao da vantagem de se

usar cache quando o servidor responde a vrios pedidos de vrios clientes. O
servidor mantm os dados enviados em cache, para permitir uma rpida resposta
caso esse mesmo dado seja requisitado novamente. No caso de se ter muitos
clientes, tm-se muitos pedidos diferentes, fazendo com que as tabelas do cache
sejam atualizadas com freqncia, sem a reutilizao dos dados l contidos.
Caso se tenha cache do lado dos clientes, ao se alterar um arquivo que est sendo
usado por muitas outras mquinas, o servidor ter que avis-las que o cache local
das mesmas est invlido e todas devero se atualizar com a verso do servidor,
causando sobrecarga.
Por outro lado, caso se tenha estimado que a rede seria muito grande e se te-
nha distribudo sistema de arquivos em muitos servidores, fica difcil descobrir
onde um arquivo est armazenado fisicamente. Por exemplo, se para abrir um
arquivo um cliente tiver que perguntar para cada servidor se ele o respons-
vel por aquele arquivo, certamente haver um congestionamento na rede. Caso
se tente resolver isso colocando um servidor central para resolver todos os ca-
minhos para os arquivos, indicando a localizao do mesmo, tal servidor sofrer
sobrecarga.
Um sistema escalvel um sistema que leva em conta esses problemas e tenta

evitar sua ocorrncia quando o nmero de clientes aumenta muito. O ANDREW
um sistema de arquivos que conseguiu adotar uma soluo satisfatria [245]
para esses problemas, atravs da descentralizao das informaes e da hierar-
quizao da rede. Esse SAD descrito na sesso 7.3.5.

Segurana
Compartilhar arquivos entre vrios ambientes e usurios uma das vantagens

que os sistemas de arquivos distribudos trazem. Porm, deixar que outras pes-
soas possam acessar arquivos confidenciais um grande problema. Dessa forma,
torna-se necessrio adotar mecanismos de segurana, para evitar que pessoas de-
sautorizadas tenham acesso aos arquivos do sistema.
Sistemas Unix adotam um mtodo baseado em permisses para controlar o

acesso aos seus arquivos [246]. Cada arquivo possui informaes sobre quais
usurios podem acess-lo e de que maneira.
Nos sistemas distribudos que executam sob o Unix, quando um servidor recebe
um pedido para enviar dados de um determinado arquivo, ele tambm recebe
informaes sobre qual usurio est tentando realizar tal acesso. Com isso, veri-
fica se tal usurio tem permisso suficiente para realizar essa solicitao, fazendo
uma comparao com as informaes de permisses do arquivo.
Outra forma de implementar esse controle de segurana um sistema baseado

em capacidades [351], que consiste em enviar ao servidor uma prova de que ele
possui a capacidade de acessar um determinado arquivo. Na primeira vez que o
usurio acessa tal arquivo, enviado ao servidor sua identificao e o servidor,
por sua vez, retorna um cdigo que a sua prova de capacidade para acessar
aquele arquivo. Nas prximas requisies, o cliente no precisa se identificar
novamente, bastando apenas enviar a prova de sua capacidade. Deve-se tomar
cuidado para no criar provas de capacidade que sejam fceis de ser forjadas.
E possvel, tambm, implementar o controle de segurana atravs de listas de

controle de acesso [351], onde cada elemento da lista possui as permisses que
cada usurio tem para acessar determinado arquivo. Isso evita que se crie, por
exemplo, uma matriz de arquivos por usurios, onde cada elemento representa
o tipo de acesso (o que utilizaria muita memria, dado que muitos desses ele-
mentos seriam iguais). O sistema de arquivos distribudo ANDREW utiliza esse
mecanismo de listas de controle de acesso.
O controle no acesso aos arquivos uma das medidas de segurana para proteg-
los. Porm, caso haja outras mquinas no caminho de duas mquinas confiveis,

existe o risco de se ter dados interceptados ou, at mesmo, adulterados. Uma

forma de se resolver esse problema criptografar as informaes antes de envi-
las.
O sistema de arquivos SWALLOW [246] um sistema de arquivos distribudo

que transmite os arquivos criptografados. Ele funciona em um sistema baseado
em capacidades, onde a prova da capacidade a chave criptogrfica. A vantagem
que o servidor no precisa verificar se a prova da capacidade autntica: se ela
no for, o cliente no conseguir decodificar os dados.
Meios mais modernos e eficazes para o controle da segurana no acesso e mani-

pulao dos dados armazenados podem ser encontrados em [192].
Tolerncia a Falhas
Durante a transmisso dos dados entre servidores e clientes, falhas podem ocor-
rer, seja por excesso de trfego de pacotes pela rede, seja por algum dos servidores
estar sobrecarregado. Alm disso, podem ocorrer falhas de hardware, especial-
mente dos mecanismos de armazenamento, de transmisso, etc. Esses problemas
acontecem em grande parte porque os sistemas distribudos so implementados
sobre redes de computadores que no so totalmente confiveis.
Dessa forma, um sistema distribudo precisa usar um protocolo de comunica-

o com capacidade para deteco de erros de transmisso. Assim, caso uma
mensagem chegue alterada no seu destino, o protocolo precisa perceber isso e
retransmiti-la. Isso deve ocorrer tambm para mensagens que se perderam no
caminho. Um outro problema que a rede pode ter o seu particionamento por
tempo indeterminado.
Alm disso, o hardware dentro das mquinas tambm pode apresentar falhas.
Por exemplo, um disco rgido pode deixar de funcionar de um momento para
outro. Nesse caso, solues como redundncia fsica do equipamento (reali-
zada atravs de hardware) ou redundncia controlada pelo prprio sistema dis-
tribudo, que cuidaria de replicar os dados, j evitaria a perda das informaes
armazenadas.

Seja qual for o problema, o sistema deve evitar que o cliente fique aguardando
uma resposta por muito tempo, ou que seus dados sejam danificados ou at
mesmo perdidos. Isso significa que o servio precisa ter disponibilidade e confi-
abilidade.
Porm, essas caractersticas podem ser conflitantes se no forem bem aplicadas.

Por exemplo, para garantir a confiabilidade necessrio implementar redundn-
cia dos dados, porm a complexidade que isso gera pode aumentar demais a
carga do servidor, comprometendo a disponibilidade, pois as respostas aos clien-
tes seriam mais lentas.
Outro mecanismo que auxilia a confiabilidade a transao. Ela evita que o con-
tedo de algum arquivo fique em um estado inconsistente caso haja uma queda
do servidor ou cliente durante a execuo de alguma operao sobre o mesmo.
Maiores detalhes sobre transaes so descritas na prxima sesso.
Operaes Atmicas
Uma operao em um arquivo dita atmica quando as etapas da mesma no

podem ser percebidas por outros processos exteriores a esta operao [351]. As-
sim, antes dessa operao o arquivo apresenta um estado e aps outro, sem que
apresente nenhum outro estado intermedirio durante a operao. Caso alguma
etapa falhe durante a operao, o arquivo volta ao estado inicial.
Dessa forma, ou todas as etapas so realizadas com sucesso, ou nenhuma ser

realizada.
Operaes de leitura, escrita, criao ou remoo de um arquivo so implemen-

tadas de forma atmica pela maioria dos sistemas de arquivos.
Transaes so mecanismos que permitem realizar uma seqncia de operaes

de forma atmica. Tais mecanismos disponibilizam determinados comandos
para os usurios para que possam escolher quais operaes sero executadas
dentro de transaes. Para montar uma transao, existem os comandos incio
e fim. O comando de incio avisa ao sistema que todas as operaes a partir da-
quele ponto estaro dentro da transao e o comando de finalizao indica que

no vir mais nenhuma operao para aquela transao.
Assim, caso alguma dessas operaes falhe, o sistema ou desfaz, ou aborta todas
as alteraes que as operaes antes daquela realizaram. Isso chamado de roll-
back ou abort. Caso todas as operaes sejam executadas sem problemas ou erros,
ao chegar no fim da transao realizado um commit, ou seja, todas as altera-
es que foram executadas so efetivadas e persistidas, de tal forma que outros
processo possam perceb-las.
Com isso as transaes implementam a semntica do tudo ou nada, ou seja, ou

todas as operaes so executadas com sucesso, ou nenhuma ser executada. Isso
faz das transaes um importante mecanismo de tolerncia a falhas, pois elas
evitam que pequenas falhas prejudiquem a integridade de todo o sistema.
Embora as transaes sejam implementadas de forma praticamente obrigatria

em sistemas de bancos de dados, elas no costumam ser implementadas em siste-
mas de arquivos. Os sistemas LOCUS e o QuickSilver [246] so algumas excees
regra, pois implementam transaes em sistemas de arquivos distribudos.
Acesso Concorrente
Vrios usurios podem acessar vrios arquivos, ou os mesmos arquivos, sem so-
frer danos, perda de desempenho ou quaisquer outras restries. Isso tudo deve
ocorrer sem que o usurio precise saber como o acesso realizado pelos servido-
res. Assim, necessrio haver transparncia de concorrncia e de paralelismo.
O maior problema encontrado nas implementaes desse tipo de soluo

quanto sincronizao dos arquivos, o que inclui leitura e escrita concorrente.
A leitura concorrente pode ser implementada facilmente se no houver escrita
concorrente, pois quando um arquivo estiver sendo lido, certamente ningum
poder escrever nele. Caso tambm se queira escrita concorrente, deve-se levar
em conta que quando um cliente escreve em um arquivo, todos os leitores devem
ser avisados que o arquivo foi alterado e todos escritores precisam tomar cuidado
para no escrever sobre as alteraes que foram feitas por outros. Assim, ou vale
a ultima alterao, ou os escritores discutem entre si para tentar fazer uma fuso
das alteraes.

Para se ter uma idia da complexidade desse problema, imagine duas operaes
bancrias simultneas na mesma conta. Uma delas um saque de R$100,00 e
outra um depsito de R$1000,00. Antes dessas operaes, suponha que essa
conta possua R$100,00 de saldo e tambm suponha que esse valor esteja armaze-
nado em um arquivo de um sistema de arquivos distribudo. Quando o cliente
da conta for realizar o saque, a aplicao ir armazenar em memria o valor atual
do saldo, assim como acontecer com a aplicao do outro caixa que estar rece-
bendo o depsito. Esta aplicao, ento, ir adicionar ao saldo o valor do dep-
sito e gravar no arquivo o novo saldo, que ser de R$1100,00. Porm, a primeira
aplicao ir subtrair do valor armazenado em memria (que para seu contexto
de R$100,00) o valor do saque e gravar o resultado (R$0,00) no mesmo arquivo,
sobrescrevendo o valor l existente. Dessa forma, o cliente perderia seu depsito.
Para evitar esse tipo de problema, as aplicaes que operam dessa forma podem
agrupar um conjunto de operaes no sistema de arquivos como sendo uma nica
transao, deixando a cargo do sistema operacional gerenciar a melhor forma de
executar isso. Existem alguns mecanismos para o controle dessa concorrncia,
como por exemplo o uso de bloqueios, o controle de otimista e o de controle por
data e hora, que so encontrados em ([351], [192]).
O mecanismo de bloqueios destaca-se por ser amplamente utilizado, e baseia-se

no bloqueio do arquivo que se quer acessar antes de acess-lo, atravs de uma
chamada ao sistema operacional ou ao sistema de arquivos. Caso um segundo
processo queira usar o mesmo arquivo, tentar realizar o bloqueio, usando o
mesmo comando que o primeiro processo. O sistema operacional ou o sistema
de arquivos o avisar caso esse arquivo esteja bloqueado. Se estiver, cabe ao pro-
cesso decidir se espera na fila pelo desbloqueio ou se continua seu processamento
sem o acesso ao arquivo. Esse desbloqueio realizado pelo processo detentor do
arquivo, atravs de um comando, similar ao usado para o bloqueio.
Atravs desses bloqueios, tornar as transaes serializveis, isto , o resultado

da operao de vrias transaes simultneas o mesmo obtido se elas fossem
realizadas uma aps a outra [246]. Um protocolo para a realizao dessa seria-
lizao o protocolo de bloqueio de duas fases, onde na primeira fase ocorre o
bloqueio de todos os arquivos a serem usados nessa transao e, na segunda fase,
a liberao conjunta de todos os arquivos, aps a realizao das operaes dentro
dessas fases.

Porm esse protocolo pode gerar um travamento (deadlock), onde um processo es-
peraria a liberao de um arquivo que foi bloqueado por outro processo, que tam-
bm estaria esperando a liberao de um arquivo que foi bloqueado por aquele
primeiro processo, por exemplo. Para evitar travamentos em sistemas distribu-
dos, existem tcnicas e algoritmos que fogem do escopo deste trabalho, devido
complexidade, mas que so descritos em [192], [351].
Replicao de Arquivos
Em um ambiente distribudo, pode-se tambm distribuir a carga causada pelo

acesso aos arquivos nos vrios servidores que compe o sistema. Pode-se replicar
os arquivos em mais de um servidor, ou ento replicar somente os arquivos mais
acessados, ou ainda replicar somente os pedaos dos arquivos que costumam ter
um alto nvel de acesso. Note que o uso de cache em um sistema de arquivos
pode ser encarado como uma replicao de arquivos, embora seu objetivo seja
principalmente desempenho.
Alm disso, se um sistema de arquivos oferece essa funcionalidade, a eficincia

e a confiana do servio de arquivos generosamente aumentada. Eficincia em
termos de tempo de resposta, carga do servidor e trfego de rede. Confiana caso
um determinado servidor caia ou fique indisponvel, pois o servio de arquivos
ainda pode realizar suas obrigaes por possuir cpias dos dados em outro ponto
da rede.
Dessa forma, replicao de arquivos prov tolerncia a falhas, j que o usurio

pode no perceber que o servidor que ele estava usando caiu e que outro entrou
no lugar para prover o recurso que ele estava usando. Da o sistema tambm
deve oferecer transparncia de replicao, pois o usurio no precisa saber como
o sistema cuida da replicao desse arquivo.
O maior problema nessa caracterstica do SAD que a implementao pode ser

muito complicada, pois necessrio manter os dados sincronizados e coerentes
ao mesmo tempo.
Existem solues centralizadas e distribudas [192] para esse tipo de problema.

A centralizada consiste de um nico servidor que cuida dos pedidos dos clientes
atravs de handles. Com esses handles, os clientes acessam diretamente os arqui-
vos atravs dos servidores e secundrios. Porm, caso o servidor primrio caia,
nenhum outro cliente conseguir abrir nenhum outro handle, somente os que j
estavam abertos continuam acessando os arquivos.
No caso da soluo distribuda, existem dois tipos de implementaes: a primeira

utiliza comunicao em grupo, que consiste em quando ocorrer uma alterao
por algum dos servidores, este manda um broadcast para os outros servidores di-
zendo que o arquivo foi alterado. Estes, por sua vez, podem alterar esse arquivo
imediatamente ou somente quando forem utiliz-lo; a segunda utiliza votao e
nmeros de verso. Isso significa que quando um cliente pedir permisso para al-
terar um arquivo, os servidores votaro entre eles pra saber quem possui a verso
mais recente.
Esse servidor ser o servidor padro daquele arquivo e seu nmero de verso
ser incrementado.
Todas essas idias, alm de serem complicadas de implementar, geram alguns

problemas. Manter a sincronizao entre os servidores, para o caso de alteraes
no sistema de arquivos, uma delas.
Tal tarefa no pode interferir no desempenho (por causa da disponibilidade) e

nem no uso do sistema pelos usurios (devido transparncia).
Os Primeiros Sistemas de arquivos Distribudos
O primeiro SAD que se tem notcia, segundo [246], usava a ARPANET, rede cons-
truda pelo Departamento de Defesa dos Estados Unidos em 1969 que entrou
em funcionamento em 1973. Ele disponibilizava um repositrio de dados para
computadores que no possuam capacidade de armazenamento adequada. Era
chamado de Datacomputer e usava um servio parecido com o FTP atual.
Depois dele, veio o Interim File Server (IFS), criado por pesquisadores do Xerox
Palo Alto Research Center (PARC). Ele j organizava os arquivos privados e com-
partilhados em uma rvore de diretrios. Um sistema subseqente foi o Woods-

G UIA DE C LUSTER 7.3.4 - N ETWORK F ILE S YSTEM - NFS
tock File Server (WFS), criado tambm pelo PARC, que permitia enviar aos clientes
somente pginas dos arquivos, ao invs de enviar o arquivo completo, possibili-
tando trabalhar assim com mquinas sem discos locais.
Em 1977, o PARC criou o Xerox Distributed File System, destinado a oferecer uma
base para a implementao de sistemas gerenciadores de banco de dados. Ele
j implementava transaes atmicas envolvendo vrios arquivos e servidores,
usando um protocolo de duas fases e o acesso a pequenos trechos de arquivos.
Depois dele vieram o LOCUS (1980) que j implementava transparncia de locali-

zao, replicao e transaes atmicas aninhadas; o SWALLOW (incio dos anos
80) do MIT, que usava uma tcnica de controle de acesso concorrente baseado em
timestamps; o Acorn File Server (incio dos anos 80), desenvolvido para implanta-
o de uma rede de microcomputadores em escolas a um custo muito baixo; e o
VICE (1984), ancestral do AFS e do CODA.
7.3.4 Network File System - NFS
Projeto:Network Filesystem
Stio Oficial:http://nfs.sourceforge.net
Licena:GPL
Responsvel:
Network File System [341], [245], [246], [269], sistema de arquivos distribudo de-
senvolvido inicialmente pela Sun, o SAD mais utilizado em sistemas Unix. Em
1985 a Sun tornou pblico seu protocolo, o que permitiu que outras empresas e
desenvolvedores pudessem criar clientes e servidores compatveis.
Hoje em dia, j possvel encontrar implementaes do NFS (tanto cliente como

servidor) para quase todos os sistemas operacionais existentes, inclusive sistemas
no-UNIX, como o Windows. Isso tambm foi facilitado pelo fato do NFS definir
uma interface RPC [231] que utiliza uma representao de dados independente
de mquina chamada External Data Representation (XDR).
As verses mais usadas do NFS so as 2 e 3, porm j existe a RFC3530 [330]

que descreve o NFSv4. Assim como as verses antigas so incompatveis entre

si, essa nova verso tambm ser. As diferenas e caractersticas de cada uma
dessas verses, levando em conta funcionamento,desempenho e segurana, esto
detalhadas na seo a seguir.
Caractersticas do NFSv2 e NFSv3
Os servidores NFSv2 e NFSv3 no guardam o estado das transaes realizadas.

Isso faz com que no percam nenhuma informao enviada em caso de falha na
transmisso ou nos servios, agilizando sua recuperao. Os clientes tambm no
precisam se preocupar com essa falha, pois basta pedir os dados novamente para
o servidor, at que ele responda.
Por outro lado, servidores que no guardam o estado das transaes realizadas
no conseguem gerenciar locks e nem realizar transaes atmicas. Existem so-
lues disponibilizadas parte para resolver alguns desses problemas, como um
servidor de locks, chamado de Network Lock Manager [227], para auxiliar as pol-
ticas de acesso a arquivos de forma concorrente. Tambm pelo fato do NFS no
manter estado, ele no pode controlar o acesso concorrente aos seus arquivos e
nem garantir a sua consistncia.
No NFSv3 o mecanismo de cache do servidor foi alterado para possuir tamanho

varivel (antes era constante) e sua poltica de escrita foi alterada do write-on-
close (aps se fechar o arquivo, este gravado em disco) para o delayed-write (o
arquivo gravado em disco aps ficar algum tempo no cliente sem ser alterado).
Assim, caso um arquivo seja usado constantemente e depois apagado, nada ser
gravado.
Outra vantagem do protocolo NFSv3 em relao ao NFSv2 o fato de que este

ultimo limitava o trfego de dados de arquivos em blocos de 8KB, enquanto que
aquele permitiu enviar dados entre servidor e cliente em blocos de at 56Kbytes
via UDP. Alm disso, no NFSv2 o servidor s retorna o resultado da gravao
desses 8Kbytes aps eles estarem gravados fisicamente. Isso consumia muito
tempo pois s se gravava em blocos de 8KB. No NFSv3 o disco pode gravar uma
quantidade de dados maior simultaneamente, pois o servidor retorna uma res-
posta do pedido de escrita ao cliente antes de realmente gravar os dados no disco,
acumulando-os para escrever de uma s vez.

Segurana
No NFSv2, o cliente era responsvel pelo controle de acesso aos arquivos (sem
nenhuma validao por parte do servidor). Isso mudou na verso 3, onde o ser-
vidor passou a tomar tal deciso, usando o mesmo esquema de segurana dos
sistemas de arquivos locais Unix. Quando um cliente faz um pedido, ele envia
o uid e o gid do usurio solicitante, e, atravs de uma consulta s permisses do
arquivo local em questo, o servidor decide se libera o acesso ao cliente ou no.
Porm, isso necessita de sincronizao de uid e gid entre as mquinas da rede.

Para resolver isso foi criado o Network Information Service (NIS), um servio de
informaes distribudo que usado para fornecer tais informaes a todos os
ns da rede.
Percebe-se facilmente a fragilidade disso, dado que se um cliente no for confi-

vel ele pode fornecer uids e gids falsos, podendo, assim, acessar e alterar arquivos
de outros usurios. Para resolver esse problema, o NFS possui a possibilidade de
autenticao mtua entre cliente e servidor, baseada no mtodo DES de criptogra-
fia, onde as chaves so fornecidas pelo NIS. Porm, a informao trafegada no
criptografada, o que possibilita que intrusos possam obter pedaos de arquivos
que trafeguem pela rede.
O Novo Protocolo NFSv4
Alguns anos aps o lanamento da especificao do protocolo NFSv3, foi criada

uma nova verso que rev vrios conceitos que no estavam presentes nos pro-
tocolos anteriores, que causam mudanas drsticas [269] no que se conhecia at
ento sobre o NFS. Essa nova verso est disponvel para o Linux a partir da
verso 2.6 do seu kernel.
Nela, o servidor mantm o estado dos arquivos em conjunto com os clientes,

diferentemente das verses anteriores. Assim, possvel que um determinado
cliente pergunte ao servidor o que outros clientes esto fazendo com determinado
arquivo. Isso pode indicar ao cliente se vale a pena ou no realizar um cache dos
dados de forma mais agressiva.
possvel tambm bloquear e compartilhar partes de arquivos atravs do pr-

prio protocolo NFS, sem a necessidade de servidores externos (como o NLM). O

mecanismo para isso baseado em leases, ou seja, um cliente NFS pede ao ser-
vidor um contrato de bloqueio temporrio (lease) e deve manter contato com o
mesmo para continuar prolongando esse contrato conforme a necessidade.
Alm disso, foi introduzido um esquema de delegao de arquivos, onde o cliente

NFS pode acessar e modificar o arquivo dentro do seu cache local sem a neces-
sidade de mand-lo para servidor, at que o servidor contate o cliente avisando
que outro cliente gostaria de acessar o arquivo, quando ento este atualizado
no servidor. Isto reduz o trfego de rede consideravelmente nos casos em que os
clientes no desejam acessar um conjunto de arquivos concorrentemente.
Quanto comunicao entre cliente e servidor, o NFSv4 usa chamadas RPC com-
postas, ou seja, uma mesma chamada RPC pode conter uma operao complexa
envolvendo bloqueio, abertura, leitura, etc. Essas chamadas so realizadas atra-
vs de conexo TCP, ao contrrio das verses mais antigas, que usam UDP.
Em relao segurana, o NFSv4 possui mecanismos sofisticados, e todas as im-

plementaes de clientes obrigatoriamente devem t-los. Dentre esses mecanis-
mos esto inclusos Kerberos 5 e SPKM3, juntamente com o tradicional AUTH
SYS [160]. Alm disso, uma nova API foi criada para permitir estender esse me-
canismo no futuro.
No NFSv4 a interpretao das listas de controle de acesso (ACLs) foi padronizada

tanto para o ambiente Posix quanto para o Windows. Os nomes de usurio e
grupo so armazenados em forma de texto e no mais como valores. Alm desses,
existe a possibilidade de se ter outros atributos, conforme a necessidade. Todos
eles so armazenados na codificao UTF-8.
Por fim, todos os protocolos NFS existentes (tais como stat, NLM, mount, ACL
e NFS) convergem para uma nica especificao, proporcionando uma melhor
compatibilidade com os firewalls de rede, alm de introduzir no protocolo su-
porte a migrao e replicao de arquivos.
Anlise Crtica
O NFSv4 tornou sua manuteno e uso muito mais simples, por possuir, agora,
controle de bloqueios encapsulado no mesmo protocolo e no mais atravs de
sistemas de terceiros, alm de permitir o controle da consistncia dos arquivos

G UIA DE C LUSTER 7.3.5 - A NDREW F ILE S YSTEM - AFS
que esto nos caches dos seus clientes. O controle da segurana aos arquivos
era muito simplificado e frgil, permitindo que clientes no confiveis pudessem
acessar arquivos de maneira desonesta. Isso foi resolvido na verso 4 do proto-
colo, onde mecanismos avanados de segurana e autenticao foram incorpora-
dos.
Outro problema era o grande consumo de recursos da rede nas operaes entre
cliente e servidor (devido interface RPC/XDR). Associado poltica de cache,
o NFSv3 no muito recomendado para aplicaes que necessitam de acesso
contnuo aos arquivos. O NFSv4 resolve esse problema pois possvel enviar
mltiplos pedidos ao servidor atravs da mesma chamada RPC, alm do uso do
cache ter melhorado por conta do controle de estado no acesso aos arquivos.
Uma excelente caracterstica a transparncia que o sistema de arquivos fornece

ao usurio final, que nem sequer percebe estar lidando com arquivos remotos.
Na verso 4, onde os controles de bloqueios e estado so nativos do protocolo,
isso ainda mais evidente, dando a impresso de que se est usando o sistema
de arquivos local.
Alm disso, o fato de ter sua especificao aberta para que qualquer um possa
implementar seu servidor ou cliente permitiu que ele se tornasse o sistema de
arquivos distribudo mais utilizado no mundo.
7.3.5 Andrew File System - AFS
Projeto:Open Andrew Filesystem

Stio Oficial:http://www.openafs.org
Licena: IBM Public License Version 1.0
Responsvel:
O projeto ANDREW ([245], [246]) comeou na Universidade Carnegie-Mellon em

1983, com apoio da IBM. Seu objetivo era projetar e implementar um sistema dis-
tribudo para o ambiente acadmico de ensino e pesquisa, que ofereceria a cada
professor e aluno uma estao de trabalho com um sistema operacional compat-
vel com o UNIX BSD. Alm disso, a partir de qualquer um desses computadores,

o usurio deveria ter a mesma viso do sistema. Essa transparncia de localiza-

o deveria ser altamente escalvel, podendo aceitar de 5 a 10 mil estaes de
trabalho nessa rede.
Ao lado da escalabilidade, um outro problema importante que os desenvolvedo-

res iriam enfrentar era a segurana. Com tantos clientes e usurios, era pratica-
mente impossvel confiar em todos sem provocar uma fragilidade na segurana
de todo o sistema. O ANDREW sofreu modificaes gradualmente durante sua
existncia, que foi dividida em trs fases:
AFS-1: Durante o ano de 1985, o AFS-1 operou 100 estaes de trabalho e

6 servidores. O desempenho do sistema era razovel tendo at 20 clientes
conectados por servidor, porm um trabalho pesado que algum deles re-
alizasse poderia degradar o funcionamento do sistema como um todo de
forma intolervel. Alm disso, a administrao do sistema era complicada,
dado que os administradores no dispunham de ferramentas adequadas.
AFS-2: A partir de toda a experincia adquirida com o AFS-1 e com todos os

seus testes de desempenho, foi possvel criar uma nova verso muito mais
eficiente. Eficincia ganha com o uso de algoritmos melhores para manu-
teno da consistncia do cache, alm de uma melhoria na implementao
da resoluo de nomes, comunicao e estrutura dos servidores. Funcionou
desde o final de 1985 at meados de 1989.
O AFS-2 [245] trouxe o conceito de callback, que permite ao cliente abrir e fe-
char um arquivo vrias vezes sem precisar acessar o servidor. Quando um
cliente recebe um arquivo do servidor, ele tambm recebe um callback, que
uma promessa de que ele est com a verso mais recente do arquivo, que
pode ser quebrado ou quando um cliente atualiza um arquivo, ou quando o
servidor recebe uma nova verso desse arquivo de um outro cliente. A c-
pia local pode ser utilizada quantas vezes se desejar, contanto que o cliente
possua um callback vlido.
O problema de escalabilidade foi amenizado ao se passar grande parte do
trabalho dos servidores para os clientes: todas as operaes de leitura e
escrita so realizadas na cpia local do arquivo. Somente quando o arquivo
alterado fechado ele ento transferido de volta para o servidor. Uma
consequncia desta tcnica que o AFS utiliza semntica de sesso (e no
a semntica UNIX de acesso concorrente a arquivos). Assim, um cliente s

perceber a alterao de um arquivo, feita por um outro cliente, quando ele

abrir o arquivo depois que o outro j o tiver fechado.
Como vrios usurios passaram a depender do sistema, percebeu-se a im-

portncia da disponibilidade dos dados, j que a queda de um servidor
provocava interrupo dos trabalhos por vrios minutos. Assim, em 1987
iniciou-se o desenvolvimento de um sistema de arquivos de alta disponibi-
lidade, baseado na escalabilidade e segurana do AFS, denominado CODA
(mais detalhes na seo 7.3.6).
AFS-3: O AFS-3, ou simplesmente AFS, foi uma iniciativa de tornar o AN-

DREW um sistema comercial no incio de 1990. Para tanto, era necessrio
adotar alguns padres, como por exemplo o Virtual File System (VFS) da
SUN, possibilitando integr-lo a outros sistemas de arquivos.
Foi implementado o protocolo Kerberos para autenticao mtua entre cli-

entes e servidores, resolvendo assim o problema de segurana no acesso aos
dados. A proteo dos arquivos baseada em listas de controle de acesso,
que especificam quais usurios, ou grupos, tm que tipo de acesso sobre
eles.
Alm disso, a partir dessa implementao os arquivos deixaram de ser ca-

cheados em sua totalidade e passaram a ser transferidos, conforme a ne-
cessidade, em blocos de 64 Kbytes, reduzindo assim a latncia da abertura
e tornando possvel o acesso a arquivos grandes que no cabem no disco
local.
Princpios do AFS
A fim de atingir seus objetivos, foram adotadas algumas regras para o desenvol-
vimento do ANDREW e, conseqentemente, do AFS:
1. Sempre que for possvel deve-se realizar as operaes no cliente e no no

servidor, distribuindo, assim, as tarefas entre as mquinas disponveis, evi-
tando sobrecarregar o servidor;
2. Sempre que possvel usar o cache para diminuir o trfego dos dados e a
carga dos servidores;

3. Explorar os tipos de acesso aos arquivos. Por exemplo, manter arquivos

temporrios na mquina local, replicar em diversos servidores arquivos
executveis que so muito usados e raramente alterados, etc;
4. Replicar servios e informaes sempre que possvel, evitando limitar a es-

calabilidade de todo o sistema capacidade dessa mquina central;
5. Confiar no menor nmero possvel de entidades (segurana);
6. Agrupar o trabalho sempre que possvel. Por exemplo, realizar uma leitura
de 50 KB muito mais eficiente que realizar 50 leituras de 1 KB.
Caractersticas do AFS
O espao de nomes do AFS dividido em duas partes: os locais, que consistem

dos arquivos cacheados, temporrios e daqueles necessrios para a inicializao
da mquina; os remotos, que so aqueles que podem ser encontrados a partir de
qualquer cliente conectado na mesma rede.
Ao contrrio do NFS, no AFS toda informao sobre os nomes dos arquivos e di-
retrios armazenada nos servidores. Deste modo, a manuteno dos clientes
trivial e a uniformidade do espao de nomes uma consequncia natural da con-
figurao dos servidores. Quando um cliente precisa acessar um arquivo remoto,
ele pergunta a todos os servidores por sua localizao, que ento guardada em
cache local para futuras consultas.
O acesso concorrente a arquivos pode ser controlado a partir de chamadas UNIX

para flock, que administra bloqueios ao arquivo, de forma emulada. O respon-
svel por esse bloqueio o servidor que detm tal arquivo. Caso esse bloqueio
dure mais de 30 minutos, o servidor automaticamente o libera, para evitar que a
queda de um cliente impossibilite o acesso aos arquivos que ele bloqueou.
Em 1998 havia mais de 100 clulas AFS por todo o mundo dando a seus usurios
a possibilidade de compartilhar seus arquivos atravs de diferentes continentes
usando uma interface de sistema de arquivos parecida com a do UNIX. O AFS
comeou a ser comercializado pela Transarc Corporation, que foi comprada pela
IBM. No momento em que esse texto foi escrito, o AFS estava na verso 3.6, sendo
distribudo de forma independente do ANDREW. Para maiores informaes vi-
site: http://www-3.ibm.com/software/stormgmt/afs/library/.

G UIA DE C LUSTER 7.3.6 - C ONSTANT D ATA AVAILABILITY - CODA
Anlise Crtica
O AFS um sistema de arquivos distribudos que evoluiu muito desde sua pri-
meira verso. Pensando-se sempre em escalabilidade, transparncia de localiza-
o e segurana, ele foi implementado usando conceitos simples, mas que so de
extrema importncia para se atingir tais objetivos.
Ele oferece um servio altamente escalvel e seguro, atravs da adoo de semn-

tica de sesso no acesso concorrente a arquivos, na utilizao de grandes caches
no disco local do cliente e no uso de listas de controle de acesso, juntamente com
o protocolo de autenticao mtua Kerberos.
Por causa do cache e da iniciativa de no se compartilhar arquivos temporrios,

os clientes necessitam obrigatoriamente de disco local. O espao de nomes di-
vidido entre local e remoto, sendo que este ultimo mantido e organizado pelos
servidores atravs de um banco de dados de localizao.
7.3.6 Constant Data Availability - CODA
Projeto:CODA Filesystem
Stio Oficial:http://www.coda.cs.cmu.edu/doc/html/index.html
Licena: GPL
Responsvel: Carnegie Mellon University
O CODA 4 (Constant Data Availability) ([341], [245], [56], [246]) comeou a ser
desenvolvido em 1987 pela Universidade de Carnegie Mellon, EUA, tendo sua
origem a partir do AFS-2.Seu principal objetivo fornecer operaes desconec-
tadas ao sistema de arquivos para computadores portteis, que costumam ficar
grande parte do tempo fora da rede. Isso prov uma mxima disponibilidade dos
arquivos aos seus usurios.
Para que isso seja possvel, o CODA implementa alguns mecanismos de repli-
cao no presentes no AFS, dado que ele foi criado para lidar com estaes de
trabalho portteis ou que permanecem conectadas aos servidores por curtos pe-
4
http://www.coda.cs.cmu.edu/doc/html/index.html

rodos de tempo.
Replicao dos Dados.
Pelo CODA, cada volume (um conjunto de diretrios do sistema de arquivos)

associado a um volume storage group (VSG), que consiste de um conjunto de
servidores que replicam o volume. O conjunto de servidores acessveis de um
certo grupo em um certo momento chamado de AVSG (accessible VSG). Essa
organizao melhor visualizada na figura 7.6. A coerncia entre as vrias cpias
de um arquivo mantida por um sistema parecido com o de callbacks do AFS.
Figura 7.6: Volumes, VSGs e AVSGs
Quando um cliente envia uma atualizao de um arquivo para o servidor, a atu-

alizao enviada para todos os servidores AVSG usando um mecanismo deno-
minado multiRPC. Alm disso, so enviadas mensagens aos clientes quebrando o
callback que eles possuem para aquele arquivo, invalidando o cache do mesmo.
Se um servidor que estava cado volta rede, nada feito inicialmente para atu-
alizar seus arquivos. Porm, sempre que um cliente envia uma requisio para
abrir um arquivo para o seu servidor preferido, ele tambm pede a todos os ser-
vidores AVSG que enviem a verso daquele arquivo que eles detm. Assim, o
cliente pode descobrir se existe algum servidor com uma cpia desatualizada,
avisando-o para atualizar esse arquivo. Dessa forma, quem toma as iniciativas

para atualizao dos arquivos que possuem rplicas inconsistentes so os pr-

prios clientes.
Essa replicao aumenta a disponibilidade dos arquivos, o que aumenta a segu-

rana para os clientes encontrarem o que procuram e guardarem os dados que
possuem. Por exemplo, se um computador porttil perder todos seus dados, a
chance de recuper-los com a replicao maior. Alm disso, o espao em disco
nos servidores tende a ser maior que nos clientes, facilitando ainda mais o uso
dessa caracterstica.
Controle de Consistncia
O CODA tenta prover ao mximo as operaes desconectadas. Para isso, ele per-
mite que os clientes possam ler e escrever seus arquivos de forma indiscriminada,
a partir de qualquer servidor da rede que possua os dados que ele precise, mesmo
que a rede seja particionada devido queda de algum servidor ou conexo en-
tre eles. Isso pode gerar perda de informao e acesso a dados inconsistentes
quando, por exemplo, dois usurios alteram o mesmo arquivo em parties dife-
rentes.
Operaes Off-Line
A parte mais interessante do CODA a possibilidade de acessar um sistema de

arquivos distribudo estando completamente desconectado da rede. Se um ar-
quivo est armazenado localmente na mquina, o usurio pode ler e escrever no
arquivo sem a prvia permisso do servidor.
Isso s possvel graas a um software chamado venus 5 , que o responsvel pelo

sistema de arquivos do lado do cliente. Ele possui trs estados de funcionamento:
Cacheando: Esse seu estado normal de funcionamento. Aqui a comu-

nicao com os servidores possvel sempre que necessrio, mas o cliente
5
http://www.coda.cs.cmu.edu/doc/html/kernel-venus-protocol.html

procura estar preparado para o caso de uma desconexo da rede, seja vo-
luntria ou no;
Emulao: Esse estado atingido quando o cliente perde a conexo com

os servidores. Nesse caso, o venus tenta fazer o papel dos servidores, dis-
ponibilizando as rplicas dos arquivos gravadas localmente, como se ainda
estivessem sendo acessados atravs dos servidores;
Reintegrao: Assim que o computador conectado rede, entra-se no

modo de reintegrao, onde ele passa a fornecer aos servidores respons-
veis, os arquivos em seu cache que sofreram alteraes. Aps o final dessa
operao, volta-se ao primeiro estado.
Desempenho
Alguns testes [327] realizados em situaes normais de uso mostraram que o ta-
manho do cache local necessrio para uma semana desconectado e o tempo de
reintegrao dos dados aps esse mesmo perodo no so muito grandes.
Alm disso, concluiu-se que os problemas de acesso concorrente, que poderiam

causar conflitos na reintegrao, so raros, dado que 99% das alteraes dos ar-
quivos so realizadas pelo mesmo usurio que j o alterou anteriormente.
O desempenho com 4 servidores replicados do CODA foi no mximo 5% pior

que o do AFS, este sem replicao. Porm, o CODA se mostrou menos escalvel
que o AFS nesses testes [327].
Anlise Crtica
O CODA apresenta inovaes que auxiliam usurios que necessitam de um sis-

tema de arquivos distribudo de alta disponibilidade. Por exemplo, ele permite
que um usurio defina os arquivos que devem estar acessveis a todo momento,
dando assim a facilidade de se conectar rede por alguns instantes, atualizar seus
arquivos e os da rede e voltar a se desconectar, para ir trabalhar em casa como se
estivesse conectado.

G UIA DE C LUSTER 7.3.7 - L USTRE
A replicao dos dados permite aumentar ainda mais essa disponibilidade e a

segurana dos dados, j que no s os servidores possuem os arquivos, mas tam-
bm os clientes. O problema que isso diminui as garantias de consistncia dos
arquivos em caso de acesso concorrente.
O CODA no respeita a semntica de sesso (ao contrrio do AFS), dado que

alteraes realizadas por clientes desconectados so aceitas pelo sistema, mas no
so informadas a outros usurios. Isso tolervel, considerando o ganho extra
de disponibilidade no sistema de arquivos.
7.3.7 Lustre
Projeto: Lustre
Stio Oficial: http://www.lustre.org/
Licena: GPL
Responsvel(eis): Cluster File Systems, Inc
Lustre um sistema de arquivos distribudos de cdigo aberto, largamente utili-

zado em clusters de grande porte. O projeto tenta prover um sistemas de arqui-
vos para um cluster de dezenas de milhares de ns e pentabytes de capacidade
de armazenamento, sem comprometer a estabilidade e a segurana.
Cada arquivo armazenado em um sistema de arquivos Lustre considerado um

objeto. Lustre apresenta a todos os clientes uma semntica POSIX padro e acesso
de leitura e escrita concorrente aos objetos compartilhados. Um sistema de arqui-
vos Lustre tem quatro unidades funcionais: um Servidor de Meta dados" (MDS)
para armazenar os meta dados; um Armazenador de Alvos de Objeto (OST) para
armazenar os dados atuais; um Servidor de Objetos Armazenados (OSS) para ad-
ministrar o OSTs e cliente(s) para acessar e o usar os dados. OSTs so baseados
em dispositivos de blocos. Um MDS, OSS, e um OST podem estar no mesmo n
ou em ns diferentes. Lustre no fala diretamente e no administra OSTs, ele ape-
nas delega esta responsabilidade a OSSs para assegurar escalabilidade a grandes
clusters e supercomputadores.

G UIA DE C LUSTER 7.4 - S ISTEMAS DE A RQUIVOS PARALELOS
7.4 Sistemas de Arquivos Paralelos
Sistemas de arquivos paralelos so SADs projetados para proporcionar alto de-

sempenho sob grande demanda e concorrncia de acesso. Como essa no uma
tarefa fcil, os projetistas acabam no se preocupando tanto com a transparn-
cia no acesso, a segurana ou mesmo a qualidade do servio. Porm, isso vem
mudando.
A seguir, realizamos uma resenha de alguns SADs que tm foco em desempenho,

deixando um pouco de lado praticidade ou segurana, sendo muito usados por
aplicaes paralelas.
7.4.1 Parallel Virtual Filesystem Version 1 - PVFS
Projeto: Parallel Virtual Filesystem Version 1

Stio Oficial: http://www.parl.clemson.edu/pvfs/
Licena: GPL/LGPL
Responsvel(eis): Argonne National Laboratory e Clemson University
Atualmente os aglomerados de PCs tm se tornado cada vez mais populares para

aplicaes paralelas. Com isso, a demanda por software para esse tipo de plata-
forma tem crescido muito. Hoje em dia encontra-se todo tipo de software para o
ambiente de computao paralela, como sistemas operacionais confiveis, siste-
mas de armazenamento de dados local e sistemas de envio de mensagens.
O Parallel Virtual File System ([105], [209]) se encaixa na rea de sistemas de arqui-
vos paralelo, pois um sistema de arquivos distribudo desenvolvido para prover
alto desempenho e escalabilidade paralela para aglomerados de PCs linux. Em
geral, o PVFS promete 4 caractersticas:
Um espao de nomes consistente para todo o aglomerado;
Acesso transparente para programas e aplicaes j existentes, sem a neces-

sidade de recompil-los;

G UIA DE C LUSTER 7.4.1 - Parallel Virtual Filesystem Version 1 - PVFS
Distribuio fsica de dados em mltiplos discos e mltiplos ns;
Alto desempenho no acesso em modo usurio.
Para que um sistema de arquivos paralelo possa ser usado de maneira fcil, ele
deve prover um espao de nomes nico em todo o aglomerado e deve ser possvel
acess-lo atravs de utilitrios comuns.
Para prover acesso de alto desempenho para os clientes do aglomerado, os dados

armazenados no PVFS esto distribudos entre os vrios ns que compe o aglo-
merado, assim como o BRIDGE faz, porm usando algoritmos de distribuio
diferentes. Cada um desses ns chamado de I/O node.
Dessa forma, para se obter os dados de um determinado arquivo, necessrio

acessar vrias mquinas, utilizando-se, assim, de vrios caminhos pela rede para
chegar aos respectivos discos em que esto armazenados. Isso elimina o gargalo
da transferncia de dados que se tem quando toda a informao est em uma
s mquina, distribuindo a carga e aumentando o potencial total da banda para
mltiplos clientes.
Usar mecanismos tradicionais de chamadas de sistema para acesso a arquivos

pode ser conveniente, mas pode causar uma sobrecarga muito grande para o sis-
tema como um todo, especialmente o kernel. Assim, possvel acessar os arqui-
vos do PVFS usando uma API (Application Programming Interface) disponibilizada
como biblioteca, que contm operaes comuns, alm de outras especficas do
PVFS, que contactam diretamente os servidores, evitando acessos ao kernel local.
Essas bibliotecas, como a ROMIO MPI-IO [360], podem ser usadas pelas aplica-
es ou por outras bibliotecas para acesso de alta velocidade ao PVFS.
Os componentes do PVFS
O servidor de meta-dados (MGR na figura 7.7) um programa que gerencia to-

dos os dados que constituem informaes sobre o arquivo (exceto seu contedo),
como seu nome, sua localizao na hierarquia de diretrios, seu dono, seus atri-
butos e como seus dados esto distribudos entre os vrios ns de dados do sis-
tema. Esse programa realiza todas as operaes sobre os meta-dados dos arqui-

vos atomicamente, evitando assim ter que implementar esquemas complexos de

concorrncia, locks, consistncia, etc, para mltiplos acessos simultneos.
Figura 7.7: Viso Geral do PVFS
O servidor de dados (ION na figura 7.7) gerencia o armazenamento do contedo

dos arquivos, bem como a recuperao dos mesmos, nos discos locais conectados
nos ns. Esse servidor grava os dados dos arquivos do PVFS em um sistema de
arquivos local, atravs de chama das a funes tradicionais, como read(), write() e
mmap(), para acess-los.
Isso significa que pode-se usar qualquer tipo de sistema de arquivos local, como
Ext2, Ext3 ou Reiser [373], por exemplo. Adicionalmente possvel usar suporte a
RAID para que cada n possua tolerncia a falhas de disco de forma transparente
e confivel para todo o sistema.
Os servidores do PVFS no possuem estado, da mesma forma que o NFS, o que

simplifica sua implementao, que no considera casos como quando um cliente
se desconecta da rede sem aviso prvio. Isso pode gerar problemas de consis-
tncia, pois o servidor pode no conter a verso mais recente do arquivo (caso
o cliente possusse um cache sujo), ou algum arquivo pode ficar bloqueado para
escrita.
A API nativa do PVFS possibilita acesso em modo usurio aos servidores do

PVFS. Esta biblioteca, chamada de libpvfs, cuida das operaes necessrias para
mover dados entre os clientes e servidores, mantendo-as transparentes para o
usurio. Para operaes que necessitam de meta-dados, a biblioteca se comunica
com o servidor de meta-dados, conforme figura 7.8(a). Para acesso aos dados dos
arquivos, o servidor de meta-dados deixado de lado e os servidores de dados

so acessados diretamente, conforme figura 7.8(b). Essa a chave para se obter

um alto desempenho agregado no acesso aos dados.
Figura 7.8: Clientes acessando o PVFS
O suporte no kernel do linux para o PVFS prov as funcionalidades necessrias

para se usar comando mount nos clientes. Isso permite acesso aos arquivos do
PVFS sem necessidade de alterao das aplicaes ou programas j existentes.
Esse suporte no necessrio para se usar o PVFS, mas ele traz uma enorme
convenincia para a interatividade com o sistema. Para isso, necessrio instalar
um mdulo no kernel do linux (existe um patch para carreg-lo diretamente no
kernel ) e um Figura 7.9: Fluxo de dados pelo kernel programa chamado (pvfsd)
que se encarrega de buscar os dados para as aplicaes. Ele se utiliza da biblioteca
libpvfs para realizar essas operaes. A figura 7.9 mostra como o fluxo de dados
passa por esses componentes.
Figura 7.9: Fluxo de dados pelo kernel

G UIA DE C LUSTER 7.4.2 - Parallel Virtual Filesystem Version 2 - PVFS2
Alm disso, existe a implementao da interface ROMIO MPI-IO para o PVFS,

possibilitando que aplicaes paralelas se utilizem do PVFS sem precisar passar
pelo kernel, alm de poderem usar outras funes especficas desse sistema que
possibilitam um ajuste fino no acesso e armazenamento dos arquivos.
Anlise Crtica
O PVFS um sistema de arquivos distribudo e paralelo que se preocupa em

diminuir o gargalo provocado pelo trfego de dados, seja pela rede, seja pela
velocidade do armazenamento fsico, usando a mesma tcnica de distribuio de
dados encontrada no BRIDGE.
Alguns problemas existentes so quanto segurana no acesso dos dados, j que

se o cliente souber onde os dados esto, basta pedi-los para os ns de dados que
eles respondero, sem se preocupar com nenhum tipo de validao de permisso
de acesso. Quem cuida da permisso o servidor de meta-dados, sendo que esse
mecanismo no muito sofisticado. Outro problema existente quando o servi-
dor de meta-dados fica indisponvel. Somente os arquivos j abertos continuaro
sendo acessados, at serem fechados. Todos os outros arquivos do sistema no
podero ser acessados. Alm disso, o servidor de meta-dados pode representar
um gargalo no sistema, j que ele nico.
um sistema de arquivos paralelo que j apresenta bons resultados, mesmo

tendo problemas visveis. Para aplicaes paralelas e confiveis, em uma rede
privativa e fechada, ele pode ser usado sem grandes problemas de segurana
7.4.2 Parallel Virtual Filesystem Version 2 - PVFS2
Projeto: Parallel Virtual Filesystem Version 2

Stio Oficial: http://www.pvfs.org
Licena: GPL/LGPL
Responsvel(eis): Argonne National Laboratory e Clemson University
PVFS2 uma reimplementao das melhores caractersticas da primeira verso

do PVFS, usando uma nova arquitetura para torn-lo mais flexvel. Isso possi-
bilitou a implementao de novas caractersticas, tcnicas e inovaes que foram
sendo discutidas e requisitadas durante as correes de defeitos da primeira ver-
so.
As novidades ([315], [354]) implementadas (ou ainda a serem implementadas) no

PVFS2 e sua nova arquitetura esto detalhadas nas prximas sees.
Novas caractersticas
Suporte modular para mltiplos protocolos de rede e armazenamento
O PVFS1 foi desenvolvido com a idia de que seus dados seriam acessados via
soquete e armazenados em sistemas de arquivos locais. Analisando os aglome-
rados de computadores existentes hoje, nota-se que existem muitas tecnologias
diferentes em cada um deles, sendo que algumas so mais populares que ou-
tras. O mesmo ocorre com os sistemas de armazenamento de dados locais. Dessa
forma, o PVFS2 foi projetado usando o BMI [214] (Buffered Messaging Interface)
como interface de acesso rede e o Trove como interface de acesso ao sistema de
armazenamento fsico. O objetivo abstrair do projeto os detalhes do mecanismo
de transmisses e armazenamento. Isso permite que um desenvolvedor perso-
nalize mdulos especficos para seu ambiente, sem ter que alterar o ncleo do
PVFS2.
Acesso a dados estruturados no-contnuos
Muitas aplicaes cientficas possuem estruturas de dados complexas que nem

sempre podem ser armazenadas de forma contnua, pois isto certamente impacta
o desempenho da aplicao como um todo.
O Trove uma interface desenvolvida pela equipe do PVFS2, sendo que at

agosto de 2005 no havia um documento pblico descrevendo-a, a no ser pelo
seu prprio cdigo-fonte.
Assim como o PVFS1, o PVFS2 d suporte ao ROMIO MPI-IO, que permite ao

desenvolvedor da aplicao descrever seus dados usando tipos MPI, melhorando

o desempenho na leitura dos dados persistidos.
Distribuio de dados flexvel
No PVFS1 os dados so distribudos entre os servidores de dados usando o algo-

ritmo round-robin, isto , um arquivo dividido em blocos de igual tamanho e
cada bloco subseqente armazenado no prximo servidor, sendo que ao chegar
no ultimo servidor volta-se para o primeiro, at que todos os blocos estejam ar-
mazenados. Isso muito eficiente como uma tcnica genrica para quando no
se conhece o padro de acesso ao arquivo. Porm, em geral sabe-se qual o pa-
dro de acesso de um arquivo e isso poderia ser usado para otimizar o acesso a
ele. O PVFS2 permite que se informe esse padro de acesso e decide qual a me-
lhor forma de armazenar os dados para mxima eficincia, podendo at mesmo
utilizar-se de redundncia.
Servidores de meta-dados distribudos
No PVFS1 o servidor de meta-dados (que armazena informaes sobre estrutura

de diretrios, data de criao de arquivos, etc) centralizado, podendo represen-
tar um gargalo maior conforme o nmero de clientes aumenta.
O PVFS2 permite ter mais de um servidor de meta-dados, que pode ou no ser

um subconjunto dos servidores de dados.
Suporte explcito concorrncia
Um sistema de arquivos paralelo deve ser extremamente eficiente quanto a pro-

ver dados para vrios clientes simultaneamente.
O projeto do servidor e cliente PVFS2 foi baseado em uma mquina de estados

que est intimamente ligada a um componente de monitoramento da finalizao
das operaes em todos os sistemas envolvidos. Isto , permite-se que se realize
acesso sem bloqueios a todos os tipos de dispositivos. Isso d suporte a operaes
assncronas nativamente, facilitando a implementao do ROMIO MPI-IO.
Semnticas de consistncia ajustveis
Muitos sistemas de arquivos distribudos implementam as semnticas POSIX,

que so muito estritas. O NFS, por exemplo, no implementa essas semnticas,

pois no garante que o cache de seus clientes estejam coerentes o tempo todo.
Por existirem vantagens e desvantagens em cada tipo de semntica, o PVFS2 per-

mite que o usurio opte por uma semntica mais estrita, para permitir a imple-
mentao do ROMIO MPI-IO, ou mais relaxada, permitindo um uso mais amplo.
Mapeamento flexvel de referncias de arquivos para servidores
E possvel reconfigurar os servidores de meta-dados para escolher onde arma-

zenar um determinado arquivo. Isso muito til na administrao do sistema
de arquivos, para, por exemplo, remover um servidor ou adicionar outro. Isso
tambm pode ser feito sem a necessidade de se desativar o sistema de arquivos.
Redundncia de dados e meta-dados
O PVFS1 possui um grande problema com relao tolerncia a falhas: caso

um servidor saia da rede, perde-se o acesso aos seus dados. Pode-se utilizar
um sistema RAID de disco para evitar a perda dos dados, mas isto no garante
tolerncia falhas.
Est sendo estudado para verses futuras do PVFS2 um sistema de redundncia

relaxada dos dados. A idia realizar uma cpia dos dados e meta-dados de
um servidor em outro, utilizando-se de uma operao explcita ao cliente. Isto
significa que o cliente PVFS2 teria que realizar essa cpia.
A desvantagem nisso est em realizar operaes de forma atmica e em encontrar

formas de se evitar uma grande perda de desempenho. A vantagem que a
operao seria otimizada, ao criar as informaes redundantes em paralelo.
Arquitetura do PVFS2
Servidores
No PVFS1 cada servidor tem papel distinto: servir meta-dados ou somente da-
dos. Alm disso, o servidor de meta-dados nico. No PVFS2, cada servidor

pode atuar tanto como servidor de meta-dados como tambm de dados. A defini-
o do papel que cada um vai representar est no arquivo de configuraes, lido
durante a inicializao. Alm disso, pode-se ter mltiplos servidores de meta-
dados.
Redes
Como j mencionado, utilizando-se o BMI, possvel que o PVFS2 se comunique

por TCP/IP, InfiniBand 6.6.4 , Myricom 6.6.4 ou qualquer outro protocolo de rede
que venha a ser implementado.
Interfaces
Os clientes podem acessar o PVFS2 atravs de duas interfaces: UNIX nativo, re-
presentado pelo cliente do sistema operacional, ou ROMIO MPI-IO. Ambas as
formas seguem o mesmo perfil que foi desenvolvido para o PVFS1.
Interaes cliente-servidor
Durante o primeiro acesso ao PVFS2, os clientes acessam algum dos servidores

para obter informaes sobre a configurao do sistema de arquivos. Esse pro-
cesso ocorre de forma similar ao NFS: para abrir um arquivo, o cliente pede ao
servidor um handle. Tendo um handle, o cliente pode acessar qualquer trecho do
arquivo, desde que tenha permisso de a acesso. Quando esse handle expirar, o
servidor avisar o cliente no momento do acesso.
Esse tipo de estratgia permite que um processo possa passar seu handle a outro
processo, que evita uma nova busca pelo arquivo junto ao servidor. Como os
clientes e servidores no possuem estado, uma desvantagem que se um arquivo
removido, o cliente que tiver o handle ainda poder acess-lo por um tempo, at
expirar. Esse tipo de problema tambm ocorre em sistemas de arquivos locais.
Consistncias do ponto de vista do cliente
O PVFS2 permite que vrios clientes realizem escritas simultneas em regies

no-coincidentes dos arquivos, at mesmo em regies no-contnuas, de forma
atmica. Isso possibilita paralelizar a escrita sem correr o risco de se gerar incon-
sistncias entre servidor e clientes.

Quanto consistncia do cache, o PVFS2 permite colocar no cache do cliente a

estrutura de diretrios do servidor de meta-dados. Isso pode gerar inconsistn-
cias temporrias, pois caso haja alguma mudana em tal estrutura, o cliente ficar
desatualizado por um certo tempo (configurvel).
Consistncia do sistema de arquivos
Ao realizar alteraes na estrutura de diretrios do PVFS2, o sistema de arquivos

bloqueado enquanto essa tarefa realizada. Foi notado que esse tipo de tarefa
no representa um gargalo na maioria das aplicaes, mesmo em larga escala.
Porm, esses bloqueios no ocorrem em todas as operaes. Por exemplo, para
criar um arquivo deve-se:
1. Criar uma entrada no diretrio;
2. Criar um objeto de meta-dados;
3. Apontar a entrada no diretrio para o objeto de meta-dados;
4. Criar um conjunto de objetos de dados para o novo arquivo e apont-los

aos objeto de meta-dados.
Cada uma dessas operaes realizada atomicamente, mas o conjunto delas no.
Isso um problema para o PVFS2, caso a execuo dessas tarefas seja interrom-
pida.
Anlise Crtica
O PVFS2 realmente evoluiu muito em comparao ao PVFS original. As novas

caractersticas que esto sendo adotadas permitem que ele seja cada vez mais
utilizado, o que ajuda os desenvolvedores a entender a real necessidade que os
pesquisadores tm de um sistema de arquivos paralelo para suas aplicaes.
A mudana na forma como o cdigo foi implementado facilita sua evoluo,

atraindo desenvolvedores de plataformas especficas a criar mdulos robustos
para o PVFS2, que permitem usar esse SAP em cada vez mais aglomerados de
computadores.

Captulo 8
Cluster de Aplicao
Um cluster de aplicao um conjunto de servidores que respondem coletiva-

mente por um servio. Esse conjunto de servidores pode dividir entre si a carga
do sistema, ou simplesmente aguardar um dos servidores falhar para assumir o
servio. Esta tecnologia tem sido muito utilizada na Internet, como em sites de
portais, e-commerce, e-business, abrangendo desde situaes onde necessrio
tratar milhares de requisies simultneas, at a demanda do servio que exige
99.99% do tempo on-line por exemplo.
Clusters de aplicao, em geral, so tecnologias maduras e estveis para serem

utilizadas. E se subdividem basicamente em 2 grupos:
Alta disponibilidade;
Balanceamento de carga;
Neste captulo sero descritas tecnologias que executam ou prestam suporte para
a obteno destas caractersticas.

G UIA DE C LUSTER 8.1 - Linux Virtual Server - LVS
8.1 Linux Virtual Server - LVS
Linux Virtual Server (LVS) uma tecnologia que permite a construo de siste-
mas com alta disponibilidade e altamente escalveis, a partir do uso conjunto
de vrios servidores. A arquitetura totalmente transparente para o usurio fi-
nal, servios providos por um conjunto de mquinas so acessados atravs de
um nico servidor. O LVS pode oferecer servios de maior capacidade/desem-
penho, ou servios redundantes (quando servidores individuais tiverem que sair
do ar para manuteno) em relao aos servios disponveis em servidores nicos
(LVS-HOWTO [8]).
O LVS como um roteador da camada 4 do modelo OSI (vide a sesso 6.7.4).

A semntica padro do cliente-servidor continua preservada, onde cada cliente
pensa que est diretamente conectado a um servidor real e este pensa que est
conectado diretamente a um cliente. Nem o cliente nem o servidor sabem que
as conexes sofrem a interveno do direcionador. Um servidor real do LVS no
coopera e nem sabe da existncia de outros servidores reais no LVS, um LVS no
um beowulf (vide 10.1) e tambm no um cluster, mas se comporta como um
agregador de servios que possibilita o atendimento de uma demanda grande em
um servio (LVS-HOWTO [8]).
O cdigo IPVS, que possibilita a construo do sistema LVS, uma coleo de mo-
dificaes para kernel Linux, que combinadas com as capacidades de roteamento
e filtragem de pacotes de uma mquina Linux, transformam-na em um rotea-
dor com caractersticas especiais, capaz de balancear sesses TCP e UDP entre
vrias mquinas. Este roteador especial (balanceador de carga), chamado Linux
Director (ou simplesmente Director) distribui a carga de requisies de servios
entre as mquinas que os provem. Com isso, o sistema constitudo pela m-
quina Linux com o cdigo IPVS e as outras mquinas que hospedam os servios
chamado Linux Virtual Server (LVS), vide figura 8.1.
O sistema LVS no necessita de nenhuma modificao nos Servidores Reais (que

podem estar interconectados na mesma LAN ou geograficamente dispersos em
uma WAN) ou nos clientes. Estes por sua vez, enviam suas requisies apenas
para uma mquina (Director) no importando quantos Servidores Reais estejam
provendo os servios, que podem ser os comuns HTTP e HTTPS, servidores de
email, bancos de dados, CVS, SSH, ou seja, em geral todas as aplicaes TCP/IP

G UIA DE C LUSTER 8.1.1 - N OMENCLATURA E ABREVIAES
Figura 8.1: Esquema geral de um Linux Virtual Server
usufruem desse sistema.
O LVS prov, de maneira transparente e simples, um ambiente altamente esca-

lvel de alta disponibilidade. Seu ponto nico de falha (ponto crtico) o Direc-
tor, mas mesmo assim, em conjuno com outras ferramentas (como Heartbeat e
LDirectord) pode-se construir um sistema de alta-disponibilidade para o Direc-
tor, aumentando ainda mais sua confiabilidade e eliminando seu ponto nico de
falha.
Mais informaes e documentaes detalhadas sobre o LVS podem ser obtidas

nos seguintes endereos:
http://www.linuxvirtualserver.org
http://www.ultramonkey.org
http://www.austintek.com/LVS/LVS-HOWTO/
8.1.1 Nomenclatura e abreviaes
Em textos sobre LVS, tornou-se comum o uso de termos especficos para designar
os componentes do sistema, segue a descrio de alguns deles:

G UIA DE C LUSTER 8.1.2 - T IPOS DE C LUSTER LVS
. LVS, Linux Virtual Server - designa a combinao Director+Servidores Reais,

que juntos compem o Servidor Virtual, sendo visto pelos clientes como uma
nica mquina.
. Director - a mquina que roda o cdigo ipvs. um roteador com regras espe-
ciais que recebe requisies de servios de clientes e as repassa para mquinas
que disponibilizam os servios.
. Servidor Real - a mquina que hospeda os servios, quem de fato trata requi-
sies de clientes.
. Mtodos de Redirecionamento (LVS-Nat, LVS-DR, LVS-Tun) - Sendo o Di-

rector um roteador com regras especficas de redirecionamento, estes mtodos
determinam como os pacotes dos clientes so redirecionados para os Servidores
Reais.
. Mtodos de escalonamento (scheduling) - algoritmos usados pelo Director para

selecionar o Servidor Real que vai tratar uma nova conexo estabelecida por um
cliente.
. VIP (Virtual IP) - endereo IP usado pelo Director para fornecer os servios aos
clientes.
. RIP (Real IP) - designa os endereos IP usados pelos Servidores Reais.
. DIP (Directors IP) - endereo IP usado pelo Director para se comunicar com os
Servidores Reais.
8.1.2 Tipos de Cluster LVS
Os sistemas montados com o uso de LVS so, normalmente, descritos pelo tipo
de mtodo de redirecionamento das requisies para os ns do cluster. H trs
mtodos disponveis:
. LVS-NAT (Network address translation)
. LVS-DR (Direct Routing)
. LVS-TUN (IP tunneling)

Mais de um mtodo pode ser usado em um nico Director, tendo por base as
caractersticas dos ns do cluster. O mtodo mais simples de se implementar o
LVS-NAT.
Network Address Translation (LVS-NAT)
Em uma configurao LVS-NAT, o Director usa a habilidade do kernel Linux de

mudar o endereo IP e porta dos pacotes que passam por ele. Neste mtodo, o
Director recebe uma requisio de um cliente e a repassa para um Servidor Real,
que a processa, enviando o resultado de volta para o Director, que ento faz as
mudanas necessrias para converter o IP dos pacotes no endereo de servidor
virtual, dando resposta ao cliente, dando a este a impresso que est tratando
apenas com uma mquina, conforme figura 8.2.
Figura 8.2: LVS-NAT
Propriedades de LVS-NAT
. Os Servidores Reais devem estar na mesma subrede do Director,

. Os endereos dos ns (Servidores Reais) normalmente esto em conformidade

com a RFC 1918,
. As conexes (de entrada e sada) passam todas pelo Director,
. O Director deve ser o gateway padro dos Servidores Reais,
. O Director pode remapear nmeros de portas, isto , uma requisio recebida

em uma porta dele e pode ser redirecionada para uma porta diferente de um
Servidor Real,
. Qualquer sistema operacional pode ser usado nos Servidores Reais,
. O gargalo do ambiente pode ser um nico Director configurado para atender

a demanda, embora uma rede saturada normalmente seja o problema mais co-
mum.
Direct Routing (LVS-DR)
Neste modelo, baseado no NetDispatcher1 , o Director repassa as conexes para

os Servidores Reais e estes respondem diretamente para os clientes que fizeram
as requisies. Para isto, os Servidores Reais devero estar no mesmo segmento
de rede que o Director, assim como todas as mquinas (Directors e Servidores
Reais) que usam o mesmo VIP.
Todos os Servidores Reais possuem uma interface virtual de loopback(lo:0) confi-

gurada com o VIP que no responde a requisies ARP, redirecionando as cone-
xes que receber para uma porta local e respondendo diretamente ao cliente, o
que implica que o Director no necessita estar no caminho de volta.
Os Servidores Reais podem ser acessados de fora da rede, caso haja falha no ba-
lanceador de carga. No caso de ser usado apenas um Director e no houver outro
que atue como backup, os servidores reais podem ser acessados de fora da rede
diretamente.
1
Software de roteamento da IBM usado para balancear carga entre servidores TCP, mais infor-
maes podem ser obtidas em: http://www.cs.princeton.edu/courses/archive/
fall03/cs518/papers/networkdispatch.pdf

Figura 8.3: LVS-DR
Caractersticas do LVS-DR
. Os Servidores Reais devem estar na mesma rede que o Director,
. Os RIP no necessitam estar em conformidade com a RFC 1918,
. Somente as requisies passam pelo Director, as respostas so enviadas direta-

mente aos clientes pelos Servidores Reais,
. As portas no podem ser remapeadas no Director,
. LVS-DR permite mais Servidores Reais que LVS-NAT,
. No h sobrecarga no Director como no LVS-NAT.
Encapsulao IP-IP(Tunneling)(LVS-Tun)
IP tunneling (RFC 2003) uma tcnica que permite que pacotes IP sejam coloca-
dos dentro de outros pacotes IP, permitindo que pacotes destinados a um deter-
minado endereo IP sejam redirecionados para outro endereo. Neste mtodo
de configurao de LVS o Director e os Servidores Reais no necessitam estar no

G UIA DE C LUSTER 8.1.3 - A LGORITMOS DE ESCALONAMENTO
mesmo segmento de rede, mesmo estando geograficamente distantes (como no

caso de mirrors de ftp). Dessa forma, os Servidores Reais podem usar qualquer
endereo de rede e no apenas endereos privados.
Figura 8.4: LVS-Tun
Caractersticas do LVS-Tun
. Os Servidores Reais no necessitam estar no mesmo segmento de rede que o

Director,
. Os RIP no necessitam estar de acordo com a RFC 1918,
. O Director apenas recebe requisio dos clientes, as respostas so enviadas di-

retamente dos Servidores Reais,
. O Director no pode remapear portas,
. Os sistemas operacionais dos Servidores Reais precisam suportar IP tunneling.
8.1.3 Algoritmos de escalonamento
Existem vrios algoritmos utilizados para a implementao do LVS e seus mto-

dos de escalonamento para o balanceamento de carga. Os mtodos de escalona-
mento regulam a maneira como a carga distribuda entre os ns que compem

o sistema. Quando o Director recebe uma requisio de um cliente, atravs dos

algoritmos de escalonamento que ele decide qual n dever trata-la.
Existem mtodos de escalonamento dinmico que do maior controle sobre a

carga de chegada, com pouco ou nenhum custo adicional em processamento. O
Director mantm uma lista do nmero de conexes ativas e inativas para cada n
do cluster e usa esta informao para determinar qual n ir receber uma nova
conexo.
Os mtodos so discutidos nas sesses a seguir.
Round-Robin (RR)
O Director mantm uma lista com os endereos de cada Servidor Real, assim
que recebe uma conexo, ele a redireciona para um servidor dessa lista, onde
uma prxima conexo ser enviada para o servidor seguinte e assim continua
percorrendo essa lista de forma circular atendendo todas as requisies. Todos
os servidores da lista so tratados de igual maneira, no importando quantas
conexes esto sendo manipuladas por um servidor especfico, nem seu tempo
de resposta e/ou capacidade de processamento.
Round-Robin com pesos (WRR)
Cada n do sistema LVS possui um peso (inteiro associado sua capacidade de

processamento e atribudo pelo administrador do ambiente), baseado na quanti-
dade de carga que ele pode manipular (capacidade de processamento). O peso
ento usado, em conjuno com o mtodo round robin, para selecionar o prximo
n que ser usado quando uma nova conexo chegar, sem levar em considerao
o nmero de conexes que ainda esto ativas. Servidores Reais com pesos maio-
res tero prioridade no recebimento e quantidade de requisies, se comparados
com Servidores Reais com pesos menores.

Destination hash (DH)
Neste mtodo, o Director sempre envia requisies de um mesmo endereo IP de

origem para o mesmo Servidor Real no sistema LVS, usando uma lista esttica
de endereos de destino. O mtodo til quando o Servidor Real um servidor
proxy ou cache.
Least-Connection (LC)
Com este mtodo, quando uma nova conexo chega, o Director verifica o nmero
de conexes ativas e inativas para determinar para qual n ir enviar a requisio.
Para realizar esta escolha, o Director multiplica o nmero de conexes ativas do

n por 256 (atribuio interna do algoritmo em sua implementao) e adiciona ao
resultado o nmero de conexes inativas resultando num overhead2 para cada n.
O n com menor overhead receber a conexo. Caso haja ns com mesmo overhead,
o primeiro n encontrado na tabela do IPVS ser selecionado.
Weighted Least-Connection (WLC)
Este mtodo combina o Least-Connection com um peso para cada n (este o m-

todo padro se nenhum for selecionado), til para ser usado com ns de diferen-
tes capacidades de processamento.
O Director determina para qual n uma requisio ser enviada, calculando o

overhead, como no mtodo anterior, dividindo este nmero pelo peso associado
ao n. O n com menor valor associado aps esta operao receber a conexo.
Caso haja ns com mesmo valor associado, o primeiro da tabela do IPVS ser
selecionado.
2
Mtrica definida no algoritmo utilizada para realizar a distribuio da carga.

Shortest Expected Delay (SED)
Este mtodo pode oferecer uma sensvel melhoria em relao ao mtodo WLC
em servios que usam TCP e mantm a conexo ativa enquanto o n processa a
requisio.
O clculo do valor do overhead para o SED feito adicionando-se 1 ao nmero

de conexes ativas, dividido pelo peso associado a cada n. O n com menor
overhead recebe a requisio.
Deve-se notar o seguinte neste algoritmo:
. Ele no usa o nmero de conexes inativas enquanto determina o overhead para

cada n.
. Adiciona 1 ao nmero de conexes ativas para antecipar como o overhead ir

parecer quando uma nova conexo for realizada.
O algoritmo SED tenta minimizar o tempo de espera para cada trabalho at sua
finalizao. O tempo de espera (Ci + 1)/U i, sendo Ci o nmero de conexes do
servidor e Ui o peso fixado para este servidor.
A diferena entre SED e WLC que SED inclui a conexo que chega na funo
de custo, incrementando 1. Ele apresenta melhor qualidade em grandes sistemas
heterogneos, cujos pesos variam muito.
Never Queue (NQ)
Este mtodo apresenta uma melhoria em relao ao SED, pois caso um n no

possua conexes ativas ele receber uma nova requisio de servio. Apesar do
resultado apresentado no clculo do SED podem ocorrer situaes que uma m-
quina que no possua nenhuma conexo ativa apresente um overhead maior que
outra que possua.

G UIA DE C LUSTER 8.1.4 - C ASOS DE USO DE LVS
Locality-Based Least-Connection (LBLC)
Directors tambm podem direcionar o trfego de sada para o conjunto de servi-

dores proxy transparentes. Nesta configurao, os ns do cluster so proxy trans-
parentes ou servidores de web cache que esto entre os clientes e a Internet.
Quando o LBCL usado, o Director tenta enviar todas as conexes de um ende-

reo IP particular para o mesmo servidor proxy transparente (n do cluster). Ou
seja, a primeira vez que uma requisio chegar, o Director ir escolher um Ser-
vidor Real para atend-la usando um verso um pouco modificada do mtodo
WLC e todas as requisies subseqentes deste cliente continuaro a ser envia-
das para o servidor escolhido.
Locality-Based Least-Connection with Replication Scheduling (LBLCR)
semelhante ao mtodo anterior com uma melhoria, o Director mantm um ma-

peamento de um cliente para um conjunto de servidores que podem atend-lo.
Se todos os ns do conjunto estiverem sobrecarregados, o Director apanha um
servidor com menos conexes e o adiciona ao conjunto. Caso este conjunto no
se modificar em um intervalo de tempo especfico (seis minutos, intervalo padro
como definido no cdigo do IPVS), o servidor com maior carga ser excludo.
8.1.4 Casos de uso de LVS
Muitas empresas utilizam o LVS para suprir a demanda por uma grande capa-
cidade de processamento de requisies e para poder dividir/balancear a carga
de seus sistemas por outras localidades (mquinas remotas), melhorando assim
o atendimento das demandas de acesso a seus sistemas e stios WEB.
Alguns exemplos de stios e empresas que utilizam a tecnologia so lista-

dos abaixo. Mais casos de uso podem ser encontrados em http://www.
linuxvirtualserver.org/deployment.html.

G UIA DE C LUSTER 8.2 - C LUSTER T OMCAT
Stio Forma de utilizao

Balanceamento de carga HTTP
http://linux.com
Balanceamento de carga HTTP, HTTPS,
http://sourceforge.net FTP, SSH, CVS
http://themes.org
40 servidores Squid em 3 clusters LVS
http://wwwcache.ja.net
http://www.zope.org
Um Director rodando em modo VS/DR
www.songn.com com mais de 6 ns de servidores Windows
2000
Tabela 8.1: Exemplos de Stios que utilizam LVS
8.2 Cluster Tomcat
O Tomcat [188] um servidor de aplicaes Java, Java Servlet e JavaServer Pages

(JSP). O objetivo de um servidor de aplicaes disponibilizar uma plataforma
abstraindo do desenvolvedor de software algumas das complexidades de um sis-
tema computacional. O servidor de aplicaes responde questes comuns to-
das as aplicaes, como segurana, alta disponibilidade, balanceamento de carga
e tolerncia falhas.
Ele distribudo como software livre e desenvolvido dentro do projeto Apache

Jakarta, que oficialmente endossado pela Sun como a Implementao de Re-
ferncia (RI) para as tecnologias Java Servlet e JavaServer Pages (JSP). O Tomcat ,
suficientemente, robusto e eficiente para ser utilizado em ambientes de produo.
Tecnicamente o Tomcat um container Web, cobrindo parte da especificao J2EE

e servindo de container para tecnologias como Servlet e JSP, e tecnologias de apoio
como JNDI Resources e JDBC DataSources. O Tomcat tem a capacidade de atuar
tambm como servidor web/HTTP, ou pode funcionar integrado a um servidor
Web dedicado, como o Apache httpd ou o Microsoft IIS.
A partir da verso 5, Tomcat passou a dispor de escalabilidade horizontal (ca-

pacidade de atender ao aumento de requisies de usurios atravs do aumento
do nmero de servidores fsicos) e alta disponibilidade (capacidade de suportar

falhas de hardware ou software e manter o sistema a maior tempo possvel ativo)

por meio de suporte nativo a clustering.
O uso da metodologia de cluster permite que vrias instncias de Tomcat este-

jam disponveis para o usurio como um servidor nico, permitindo que a carga
das requisies sejam distribudas entre essas vrias instncias (balanceamento
de carga), sem o uso de recursos computacionais especializados, fazendo que o
sistema possa manipular uma quantidade muito maior de requisies antes de
uma possvel sobrecarga. O sistema construdo tambm se vale de alta disponi-
bilidade, caso um dos ns que compem o sistema caia, as requisies de usurios
continuam a ser tratadas de maneira transparente.

Figura 8.5: Viso geral de um cluster Tomcat
O modelo bsico para clusterizao em Tomcat envolve o uso de duas camadas

adicionais (figura: 8.5), uma camada responsvel pelo balanceamento de carga e
outra camada que cuidar do compartilhamento de informaes, como sesses e
outras variveis de estado, entre os servidores Tomcat.

G UIA DE C LUSTER 8.2.1 - B ALANCEAMENTO DE CARGA
8.2.1 Balanceamento de carga
H vrias opes que podem ser usadas na camada de balanceamento de carga

em um cluster Tomcat, todas elas visando distribuir as requisies de clientes
entre os servidores para melhorar a performance do sistema. Entre essas opes
sero aqui destacadas:
. DNS Round-robin.
. Hardware especializado.
. Apache mod_jk/mod_jk2.
. Balanceamento de carga via software, como LVS (switch de camada 4).
DNS Round-robin
DNS Round-robin a soluo mais simples de ser implementada, usando uma lista
de IPs dos servidores Tomcat, percorrendo-a de maneira circular enviando cada
nova requisio para um IP Tomcat diferente. Muito embora seja uma soluo
prtica de ser implementada, ela no leva em considerao a carga da mquina
para a qual uma requisio ser enviada, no apresenta vantagens em relao a
tolerncia a falhas, j que no toma conhecimento de quais mquinas esto ativas,
podendo enviar conexes para mquinas inativas, entre outros reveses.

Figura 8.6: Balanceamento de carga via DNS Round-Robin
Em servidores DNS configurados para prestar este tipo de servio, um endereo

(ex. www.seudominio.com) resolvido para os IPs dos servidores que hospe-
dam as instncias de Tomcat. Quando um cliente faz uma requisio, o servidor
DNS escolhe um dos IPs e o passa para o cliente.
Hardware especializado
Geralmente, hardware especializado para balanceamento de carga, tambm co-

nhecido como roteador de camada 4/7, um dispositivo fsico que redireciona
conexes para um conjunto de mquinas em uma rede interna. A deciso para o
balanceamento baseada na anlise de uma srie de fatores como carga do pro-
cessador, conexes ativas no servidor, entre outros. Isso minimiza a sobrecarga
dos servidores alm disponibilizar os servios hospedados nestas mquinas atra-
vs de um nico IP, mapeando as conexes para os IPs internos dos servidores.
Entre as vantagens do uso deste tipo de soluo para balanceamento de carga em

clusters Tomcat em relao ao uso de DNS Round-robin simples so:
. Balanceamento de carga mais otimizado, j que fatores como carga de proces-

sador e nmero de conexes ativas so levadas em considerao.
. Conexes dos clientes no sero enviadas para mquinas que no possam

atend-las.
As principais desvantagens so o custo destes dispositivos, a relativa complexi-

dade de configurao e o fato de constituirem um ponto nico de falha.

mod_jk
O Apache e seu mdulo mod_jk2 podem ser usados para:
. Distribuir conexes entre vrias instncias de Tomcat.
. Detectar falha em instncias, evitando o envio de requisies a servidores Tom-

cat que no estejam respondendo.
. Caso uma instncia deixe de responder, mod_jk2 verifica periodicamente se ela

voltou, caso a instncia volte a responder ela posta junto com as outras ins-
tncias em funcionamento, voltando a receber requisies.
Figura 8.7: Balanceamento de carga via Apache mod_jk
As requisies so distribudas com mod_jk2 atravs de um algoritmo de Round-

robin podendo ser levado em conta um fator de carga (peso associado a cada
instncia que regula a prioridade com a qual recebem conexes).
O mod_jk2 trabalha tambm com sesses persistentes (sticky sessions) que asse-
gura que todas as requisies com mesma sesso sero tratadas pelo mesmo n
Tomcat. A desvantagem desde mtodo que caso uma instncia deixe de funci-
onar, a sesso associada a ela ser perdida.
Balanceamento de carga via software

G UIA DE C LUSTER 8.2.2 - C OMPARTILHAMENTO DE SESSES
Entre as solues usadas para balanceamento de carga via software, uma das mais
conhecidas o LVS. Classificado como um roteador de camada 4, trata-se de mo-
dificaes includas no kernel Linux usadas para redirecionar conexes TCP de
maneira transparente para o usurio.
De maneira geral, funciona como o balanceamento feito com hardware especiali-

zado. Uma mquina com o sistema operacional Linux (conhecida no jargo LVS
como Director) possui o IP que ser acessado pelos clientes. O Director, usando
seus algoritmos de escalonamento, decide para qual mquina a conexo ser re-
direcionada. Qualquer servio TCP pode ser redirecionado, incluindo requisies
a mquinas que componham um cluster Tomcat.
O LVS mantm algumas informaes sobre os servidores (como nmero de co-

nexes ativas) para o processo de deciso do balanceamento e tambm no envia
conexes a um servidor que no esteja ativo.
8.2.2 Compartilhamento de sesses
As solues para balanceamento de carga resolvem o problema da distribuio

das requisies dos clientes entre os ns que compem o sistema. A outra ca-
mada, mostrada na figura 8.5, serve a outro propsito, assegurar que sesses e
outras informaes no sejam perdidas caso o servidor Tomcat, que as manipula-
vam, caia.
Na camada de compartilhamento, mostrada na figura 8.5, podem ser usados al-

guns tipos de back-ends, cada qual com suas funcionalidades. O compartilha-
mento de informaes nesta camada pode assegurar que a perda de conectivi-
dade de um dos servidores Tomcat que compem o cluster seja manipulada de
forma a no gerar transtorno para o usurio.
Sticky sessions em compartilhamento de sesses
Neste tipo de configurao, o balanceador de carga mod_jk2 assegura que as

requisies de uma mesma sesso sero sempre tratadas pela mesma instncia
Tomcat. Este tipo de configurao conveniente a muitos cenrios de produo,

G UIA DE C LUSTER 8.3 - H EARTBEAT
apresentando as seguintes caractersticas:
. Escalabilidade para a aplicao provida por algoritmo Round-robin, que cria no-
vas sesses no prximo n livre na fila round-robin.
. Simplicidade de implantao e manuteno.
. Nenhum tipo de configurao adicional ou sobrecarga de recurso.
Apesar das vantagens, as sesses so perdidas se o servidor que as manipula cai.
Stiky sessions com gerenciamento de sesses persistentes e armazenamento

compartilhado
A partir da verso 5, Tomcat passou a dispor de um sistema de gerenciamento

de sesses persistentes. O propsito deste mecanismo manter as sesses ativas
caso haja desligamento e reincio de servidor. Para tanto, as sesses so gravadas
em disco ou em SGBD, o que garante a manuteno da informao mesmo que
o servidor seja desligado. Esse mecanismo, a princpio, no foi desenvolvido
para atender demanda de implementao em cluster, entretanto em sistemas de
arquivos compartilhados ou SGBD essas informaes estaro disponveis para
todas as instncias de Tomcat que compem o sistema.
Um diretrio para armazenamento das sesses acessvel a todos os servidores

Tomcat atravs de mecanismos como SMB, NFS, OCFS2, assim as sesses podem
ser criadas ou modificadas por todas as instncias. Isto tambm garante uma me-
nor perda de informao em caso de problemas com o sistema e procedimentos
de recuperao.
8.3 Heartbeat
O High Availability Linux Project3 (Projeto Alta Disponibilidade Linux) tem por
objetivo desenvolver solues para GNU/Linux que promovam confiabilidade,
3
stio do projeto: http://www.linux-ha.org/

G UIA DE C LUSTER 8.4 - Z OPE C LUSTER
disponibilidade e suportabiidade (serviceability) atravs do esforo de uma comu-

nidade de desenvolvimento.
O Heartbeat, fruto deste projeto, um software que gerencia falhas de recursos

entre dois computadores, procurando eliminar pontos nicos de falhas aumen-
tando a disponibilidade do sistema formado por estes computadores. O principio
de funcionamento o de heartbeat (o conceito no se resume ao software), onde um
componente de um sistema de alta disponibilidade responsvel por monitorar
os servios do sistema trocando mensagens entre os servidores para verificar se
ainda esto ativos.
Normalmente o Heartbeat trabalha com os conceitos de servidor primrio e secun-

drio, ou seja, um servidor que de fato atende a demandas (primrio) e outro que
fica em espera para assumir os servios caso algo de errado acontea ao primrio.
Neste ambiente, um intervalo de tempo para troca de mensagens entre os servi-
dores especificado; caso no haja troca de mensagens, o Heartbeat entende que o
primrio est fora do ar; assumindo assim o servidor secundrio os servios que
eram disponibilizados.
Para verificao do estado de cada n, o Heartbeat pode usar uma ou mais cone-
xes fsicas, podendo ser a conexo ethernet normal para comunicaes de rede,
interfaces dedicadas ligadas por cabo crossover ou atravs de cabo serial. A co-
nexo normal de rede no recomendada por conta do trfego de dados das
aplicaes que ela suporta, sendo ideal o uso de interfaces dedicadas ligadas por
crossover ou mesmo cabo serial, que uma boa opo pela simplicidade e segu-
rana e tambm por ser usada apenas para esse fim.
8.4 Zope Cluster
H uma relao no linear entre o aumento de acesso a um servidor WEB e seu

tempo de resposta s requisies. O uso de uma mquina mais poderosa geral-
mente no a resposta para o problema. Uma soluo usar mais de um servidor
para realizar o trabalho e distribuir as requisies de servios entre eles.
Normalmente, um sistema que produz pginas dinmicas chamado servidor

de aplicao, que composto, tipicamente, por trs partes distintas: um servidor

HTTP, um banco de dados e alguma aplicao (middleware) que serve de inter-
face aos outros dois componentes. Estas trs partes podem estar todas em uma
mesma mquina para o caso de sistemas que no se espera muita carga. Para
o caso de sistemas com alta carga, os diferentes requisitos de cada componente
sugerem separao para hardware adequadamente ajustado para atender s suas
necessidades.
Zope uma soluo que integra um servidor Web (ZServer), middleware e um

servidor de dados (ZODB) em um nico pacote. Como parte desta soluo, Zope
pode emular a separao entre o servidor WEB e o servidor de dados atravs de
ZEO (Zope Enterprise Objects).
ZEO uma parte do sistema Zope que permite que um Zope Object Database seja
compartilhado entre mais de um processo Zope. Com o uso de ZEO, pode-se ro-
dar mltiplas instncias de Zope em um nico computador ou em vrios compu-
tadores, acrescentando escalabilidade ao sistema, j que, para atender ao possvel
(e muito provvel) aumento de demanda, mais mquinas podem ser acrescenta-
das ao sistema, alm do aumento de confiabilidade, caso uma mquina apresente
problemas as outras ativas podero atender a requisies at que a falha seja re-
solvida.
Os servidores Zoe (instncias do Zope) que servem a aplicao aos clientes (da
Internet ou Intranet) so chamados de clientes nesta arquitetura j que acessam o
servidor de aplicao.
Os clientes e servidores ZEO se comunicam atravs de TCP/IP, o que permite

que eles sejam distribudos, inclusive, geograficamente, sendo capaz de gerenciar
uma grande quantidade de requisies simultneas, a partir de hardware de baixo
custo. A nica ressalva em relao a esta arquitetura e que no h mecanismos de
redundncia nativa do ZODB (servidor de armazenamento). Isso pode ser resol-
vido com o uso de hardware especializado (sistemas de armazenamento externo)
ou com dispositivo de bloco como DRBD que pode ser usado para a replicao
do banco. Combinado com alguma ferramenta de monitoramento (Heartbeat ou
Keepalived), pode-se conseguir redundncia para o servidor de armazenamento
com o uso de hardware no especializado.
Nativamente no h suporte a balanceamento de carga no Zope, sendo necessrio

o uso de ferramentas externas. Vrios mtodos podem ser utilizados para distri-
buir as requisies dos clientes entre os servidores ZOE, como DNS round-robin,
o mdulo mod_proxy do servidor http Apache ou switch de camada 4, sendo o
LVS o mais conhecido deles.
Uma soluo, para o caso de servidores de pginas estticas, usar DNS round-
robin para distribuir as requisies recebidas por uma URL entre vrios IPs de
uma rede interna, sendo cada nova requisio enviada para um servidor dife-
rente da anterior. Sendo idntico o contedo de todos os servidores, esse pro-
cesso transparente para o usurio. Contudo, esta uma soluo atraente por
sua simplicidade entretanto apresenta seus reveses; por exemplo, arquivos de di-
ferentes tamanhos geram eventualmente mais carga para alguns servidores que
para outros. Outro problema que o servidor DNS do cliente pode fazer cache do
endereo IP acessado e usar este mesmo dado para uma consulta futura.
Figura 8.8: DNS round-robin
O DNS round-robin uma maneira de se resolver um nome para vrios endereos

IP fazendo uso do servidor de DNS para realizar a funo de balanceamento de

carga, sem o uso de uma mquina dedicada para isso. O servidor DNS resolve
www.dominiozope.com, por exemplo, para os endereos IP de ZEO Server1, ZEO
Server2 e ZEO Server3 para os clientes 1, 2 e 3, respectivamente.
Outra soluo o uso de balanceamento de carga dinmico, tambm tratado

como roteador de camada 4. Neste caso um endereo especifico resolvido para
apenas um IP que pertence ao roteador que por sua vez, transparentemente, redi-
reciona as conexes para um grupo de servidores em cluster. Preferencialmente,
estes servidores possuem a capacidade de informar sobre sua carga de trabalho
ao roteador, que depois de obter essa informao decide a qual servidor enviar
uma nova requisio. Uma soluo em software muito utilizada para isso o LVS,
parte integrante do kernel Linux que o transforma em um switch de camada 4.
O outro problema da arquitetura de cluster Zope a falta de redundncia nativa

do servidor de armazenamento. Uma maneira de se retirar esse ponto de falha,
alm do uso de hardware especializado, o uso conjugado de DRBD, OCFS2, He-
artbeat ou Keepalived e LVS. O uso de DRBD (verso 0.8 ou superior) pode ser
usado com OCFS2 para se criar um dispositivo que possa ser acessado por duas
mquinas com instncias ZODB lendo e escrevendo ao mesmo tempo. Heartbeat
ou Keepalived verifica o estado de sanidade dessas mquinas, tomando providen-
cias necessrias (reincio, notificao administrativa) caso haja algum problema.
O LVS, que pode ser usado como balanceador de carga de requisies clientes,
pode tambm balancear a carga dos ZEO clientes quando acessarem os servido-
res ZODB.

Figura 8.9: ZEO/ZODB + LVS+OCFS2

Captulo 9
Cluster de Banco de Dados
Na maioria das aplicaes que se encontram em produo os dados da aplicao

so armazenados em um servidor de banco de dados. Dessa forma o banco de
dados se torna um componente crtico na soluo da aplicao, uma interrupo
no servio de banco de dados, ou uma pequena corrupo dos dados pode afetar
totalmente a integridade da aplicao.
Existem muitas formas de se trabalhar com banco de dados de forma a se ob-

ter maior performance e/ou para obter outras caractersticas desejveis que no
esto disponveis facilmente nos SGDBs mais conhecidos.
Algumas das reas de pesquisa e desenvolvimento de bancos de dados mais

avanados so apresentadas a seguir.
Design de bancos de dados distribudos.
O design de banco de dados distribudos responsivo uma preocupao bsica

para os sistemas de informao. Em redes com grande largura da banda, latncia
e processamento local so os fatores mais significativos para consultas e atualiza-
o de dados no que se refere ao tempo de resposta do sistema. O processamento
paralelo de consultas pode ser usado para minimizar os efeitos, particularmente
se for considerado no momento do design do sistema de banco de dados. O design
de banco de dados distribudo pode ser visto como um problema de otimizao

G UIA DE C LUSTER CAPTULO 9 : C LUSTER DE B ANCO DE D ADOS
que requer solues que possuem relao com: a fragmentao de dados, a alo-
cao de dados, e a otimizao local.
Processamento de consultas distribudo.
Em sistemas distribudos de grande escala, freqentemente difcil achar um

plano timo para consultas distribudas: sistemas distribudos podem ficar muito
grandes, envolvendo milhares de parques computacionais heterogneos. Como
novos bancos de dados podem ser adicionados/removidos do sistema, fica mais
difcil para o processador de consulta" manter estatsticas precisas das relaes
participantes armazenadas nos diferentes sites e das operaes de consulta rela-
cionadas. Tambm, como a carga de trabalho dos vrios servidores de processa-
mento e a velocidade de transmisso dos links entre eles flutuam durante o tempo
de processamento dos trabalhos, h a necessidade de mecanismos de consulta
distribudos, que dinamicamente se adaptem a grandes ambientes distribudos.
Controle de Concorrncia.
O Controle de concorrncia (CC) permite os usurios acessar um banco de dados

distribudo mantendo a impresso que est acessando o banco de dados em um
sistema dedicado.
Para isto, so necessrios mecanismos de CC que intercalem a execuo de um

conjunto de transaes debaixo de certas regras de consistncia, enquanto ma-
ximizam a capacidade de execuo concorrente do sistema. As duas principais
categorias de mecanismos de CC so:
Concorrncia Otimizada - Retardo da sincronizao das transaes at que

as operaes sejam confirmadas. Conflitos so menos provveis mas no
sero conhecidos at que eles aconteam, tornando operaes de rollback
mais caras.
Pessimista - As execues potencialmente concorrentes de transaes so

sincronizadas no incio de seus ciclos execuo. Desta forma, fica mais fcil
realizar o bloqueio, entretanto os problemas devem ser conhecidos anteri-
ormente para diminuir os custos de rollbacks.

Processamento de Transaes.
Transaes distribudas provem unidades de execuo segura que permitem que

vrias operaes sejam executadas em locais diferentes e provem a preserva-
o da consistncia dos dados de um estado de execuo para outro. Um proto-
colo comum para assegurar cumprimento correto de uma transao distribuda
o de execuo em duas fases (two-phase commit - 2PC). Enquanto o 2PC
normalmente aplicado para transaes que so executadas em um curto perodo
de tempo, ele se torna impraticvel para transaes distribudas de grande escala
por causa do lock de recursos disponveis/utilizados concorrentemente. Para
isto, existem diferentes propostas, como a de dividir a execuo de processos que
ocupam muito tempo em sucesses menores de tarefas atmicas e a definio de
mecanismos de compensao.
Replicao de Dados.
O desafio fundamental na replicao de dados manter um baixo custo nas atu-

alizaes enquanto se assegura a consistncia dos parques computacionais do
cluster. A dificuldade do problema aumenta significativamente em ambientes de
larga escala devido a latncia alta e a probabilidade de quedas da rede. As duas
principais categorias de tcnicas de replicao de banco de dados so:
Replicao sncrona - implica em um protocolo de commit" atmico ao

longo do qual assegura consistncia alta s custas de transaes mais lenta
e a presena de deadlocks.
Replicao assncrona - as atualizaes so processadas periodicamente

por todos os ns do cluster, permitindo um processo de transao mais efi-
ciente, ao custo de uma baixa garantia da consistncia global dos dados.
Integrao de Dados.
Conflitos diferentes surgem da representao descoordenada de conceitos ao se

integrar fontes de dados autnomas e distribudas. Exemplos destes conflitos

so: tipo de dados, estrutura, conflito de nomes, atributos perdidos, e conflitos de

generalizao. Todos estes conflitos podem ser estaticamente endereados entre
eles, durante integrao dos esquemas de dados ou dinamicamente na gerao
de viso/consultas. De acordo com a arquitetura de integrao, e a estratgia de
manipulao de consultas, sistemas de integrao de banco de dados podem ser:
Sistema de Multi-banco de dados - coleo de bancos de dados integrados

nos quais cada DBMS mantm controle em cima de seus bancos de dados
locais, mas coopera com a federao aceitando operaes globais.
Sistema de mediador - bancos de dados so integrados, atravs de um com-

ponente de mediao que executa traduo de dados em um modelo de
dados cannico comum.
Sistemas de Metadados - consultas so formuladas dinamicamente em

cada banco de dados pela interao com um dicionrio de metadados glo-
bal.
Existem vrios tipos de clusters" de banco de dados:
Banco de dados distribudos: Nesse tipo de banco de dados os dados so

distribudos em um conjunto de servidores. O acesso ao banco de dados
direcionado ao servidor onde se encontra o dado.
Banco de dados em alta disponibilidade: Dois ou mais servidores em cluster

de alta disponibilidade (MASTER/SLAVE), onde um servidor MASTER
responsvel pelo servio e os servidores SLAVE ficam aguardando a falha
do MASTER para assumirem o servio.
Banco de dados em alta disponibilidade e distribudos: um cluster de

banco de dados onde as duas tecnologias anteriores esto presentes, criando
um banco de dados escalvel e tolerante a falhas.
Possveis tecnologias de cluster de banco de dados:
Gerenciamento do cluster na aplicao: Nessa alternativa o gerenciamento

do cluster realizado na aplicao que acessa o banco de dados. A aplica-
o que controla a distribuio e replicao dos dados. Vantagem: Pode ser

Independente de sistema de banco de dados. Desvantagem: dependente

da aplicao que est acessando o banco de dados. Exemplo de soluo:
Sequoia (ver 9.5.1), compatvel e possui a mesma sintaxe do JDBC e para
ser utilizado em uma aplicao que escrita em java so necessrios pou-
cos ajustes na aplicao. Capaz de clusterizar" qualquer banco de dados
ODBC.
Gerenciamento do Cluster no prprio banco de dados: Nesta alternativa o

gerenciamento do cluster implementado atravs de uma ferramenta in-
terna do prprio sistema de banco de dados. Vantagem: Possui maior in-
tegrao com o sistema de banco de dados, sistema mais robusto de in-
tegridade de dados, maior integrao com o sistema de banco de dados.
Desvantagem: dependente do sistema de banco de dados. Exemplos:
Soluo Proprietria: Oracle Real Aplication Cluster (RAC), Solues Livres:
Mysql Cluster(ver 9.4), PGcluster (ver 9.3.2).
Criao de um Proxy de banco de dados: Semelhante ao gerenciamento na

aplicao, s que neste caso criado um servio falso" (honeypot) onde so
feitas as conexes e o gerenciamento da distribuio das requisies para os
servidores de banco de dados reais.
LVS + Filesystem distribudo e compartilhado: Em ltima instncia banco

de dados arquivo armazenado em disco, essa idia consiste em ter um sis-
tema de arquivos nico entre os servidores, que suporte acesso de escrita
compartilhado (implementao via software das funcionalidades de uma
SAN - Storage Area Network) e um sistema que realize o balanceamento de
conexes TCP/ip entre os servidores. Funcionamento: Quando um usurio
tenta realizar uma operao de escrita no banco de dados, ele direcionado
atravs do LVS para um dos servidores de dados, onde processada a re-
quisio como se o banco no estivesse em cluster. Aps a escrita ter sido
armazenada em disco todos os outros servidores sero capazes de reconhe-
cer transparentemente as alteraes realizadas. Um problema nesse tipo de
soluo o cache do servidor de banco de dados que tem de ser reduzido
para o mnimo possvel (Atomic Operations, Atomic Transactions).
A rea de banco de dados bastante sensvel e as tecnologias esto comeando

a se consolidar, necessrio realizar muitos testes para se definir qual a melhor
tecnologia a ser adotada para cada situao.

G UIA DE C LUSTER 9.1 - B ANCO DE D ADOS D ISTRIBUDOS
9.1 Banco de Dados Distribudos
Definies
1. Segundo C. J. Date [138],

Um sistema de banco da dados distribudos consiste em uma coleo de
locais, conectados por alguma rede de comunicao e que:
a. Cada um dos locais um sistema de banco de dados completo com

seus prprios direitos, mas
b. Os bancos de dados locais trabalham em conjunto para que os usurios
que acessam os dados de qualquer outro local da rede possa acessar os
dados de forma transparente.
2. Um banco de dados distribudo um banco de dados que est sob o con-

trole de um sistema de administrao de banco de dados central, no qual
dispositivos de armazenamento (storage) so anexados a um computador.
O armazenamento pode ser em vrios computadores localizados no mesmo
local fsico, ou dispersos em uma rede de computadores interconectados.
O banco de dados, pode ser distribudo fisicamente atravs de mltiplos
locais. Um banco de dados distribudo dividido em vrias partes ou frag-
mentos. Essas partes ou fragmentos do banco de dados distribudo podem
ser replicadas, para por exemplo criar ambientes de redundncia, RAID, ou
mesmo copias para Data Warehouse.
Alm de replicao e fragmentao em banco de dados distribudos, exis-
tem vrias outras tecnologias para design de banco de dados distribudos.
Por exemplo, autonomia local, tecnologias de bancos de dados distribu-
dos sncronos e assncronos. A implementao destas tecnologias podem
e definitivamente dependem das necessidades das reas de negcios e de
a sensibilidade e confidenciabilidade dos dados a serem armazenados no
banco de dados.
9.2 Replicao de Banco de Dados
Um banco de dados replicado um sistema de bancos de dados com c-

pias distribudas em uma ou mais mquinas. Este tipo de sistema oferece

G UIA DE C LUSTER 9.2 - R EPLICAO DE B ANCO DE D ADOS
alta disponibilidade e tolerncia a falhas, j que no h apenas uma nica

cpia dos dados, e melhoria de desempenho, posto que as requisies no
oneraro apenas uma fonte de dados.
Para se implementar a replicao em bancos de dados podem ser usados

dois mtodos levando-se em considerao a maneira como feita a propa-
gao de uma atualizao.
Uma primeira aproximao chamada replicao sncrona, ou seja uma

atualizao (modificao fruto de uma operao de UPDATE, INSERT ou
DELETE, por exemplo) s consumada se for realizada em todos os ns
que compem o sistema. Isto significa que o cliente ter de esperar at que
todas as instncias do banco de dados sejam modificadas para receber uma
confirmao, garantindo a integridade da informao entre os ns.
A outra aproximao realizar a atualizao de maneira assncrona, ou seja

as modificaes so difundidas entre os ns aps ser efetivada em um servi-
dor e a resposta ser enviada ao cliente. O tempo de resposta, se comparado
ao mtodo anterior menor, porm isto pode gerar inconsistncias entre as
replicas.
Uma maneira de se contornar estes problemas restringir as atualizaes

a um nico n, chamado cpia primria ou MASTER, o que impede que
atualizaes em um mesmo objeto sejam feitas em duas mquinas diferen-
tes. Todas as operaes de modificao no banco sero enviadas para esta
mquina que cuidar de propagar as modificaes. A contrapartida para
este modelo permitir atualizaes em qualquer banco que componha o
sistema, no introduzindo uma rplica privilegiada mas requerendo um sis-
tema que resolva conflitos de possveis inconsistncias.
O uso de middleware (software interface entre os clientes e o sistemas de ban-

cos de dados) se tornou um atrativo, j que permite a construo de sistemas
replicados sem a necessidade de modificao do sistema de gerenciamento
de banco de dados, nem no banco de dados em si. Em sistemas desta natu-
reza as requisies so enviadas ao middleware que se encarrega de propag-
las s rplicas de maneira a prover controle de replicao e balanceamento
de carga.
Dentre os bancos de dados livres dois vem se sobressaindo no ambiente cor-

porativo, o Mysql[13] e o Postgresql[19], dos quais veremos alguns detalhes
sobre a clusterizao e replicao de dados.

G UIA DE C LUSTER 9.3 - P OSTGRE SQL
9.3 PostgreSQL
O PostgreSQL um SGBD (Sistema Gerenciador de Banco de Dados) objeto-

relacional de cdigo aberto, com mais de 15 anos de desenvolvimento.
extremamente robusto e confivel, alm de ser extremamente flexvel e rico
em recursos. Ele considerado objeto-relacional por implementar, alm das
caractersticas de um SGBD relacional, algumas caractersticas de orienta-
o a objetos, como herana e tipos de dados personalizados. A equipe
de desenvolvimento do PostgreSQL sempre teve uma grande preocupa-
o em manter a compatibilidade com os padres SQL92/SQL99/SQL2003
(Postgresql-BR [19]).
As capacidades de Replicao e Clusterizao so feitas atravs de mid-

dlewares externos prprios para o PostgreSQL, como o PGpool e o PGcluster,
que so detalhados a seguir.
9.3.1 PGpool
PGpool[18] um middleware para PostgreSQL, distribudo sob licena BSD,

que se situa entre os clientes e os servidores de banco de dados provendo
alta disponibilidade, replicao e balanceamento de carga. Alm destas
caractersticas em comum com outros sistemas similares, PGpool adicio-
nalmente salva as conexes com os servidores PostgreSQL por ele coor-
denados (PGpool atualmente trabalha apenas com dois servidores Post-
greSQL), reutilizando-as quando uma nova conexo com mesmas propri-
edades (nome de usurio, banco de dados, protocolo) chega, reduzindo so-
brecarga de conexo e aumentando a taxa de transferncia de todo o sis-
tema.
Como sistema de replicao de dados, PGpool permite backup em tempo

real de bancos de dados, enviando as mesmas declaraes SQL para ambos
os servidores, podendo ser considerado um sistema de replicao sncrona.
Apesar disto algumas instrues SQL so dependentes do servidor no qual
so executadas como funes aleatrias, OID, XID e timestamp, no sendo
replicadas com o mesmo valor para ambos servidores.
Se algum problema torna um dos servidores PostgreSQL indisponvel, o

PGpool tenta continuar o servio com o servidor ainda ativo, este modo
chamado modo degenerado". Inconvenientemente, o PGpool no oferece

G UIA DE C LUSTER 9.3.1 - PG POOL
nenhum mtodo para voltar um servidor com problemas de novo no clus-

ter, sendo necessrio que os bancos sejam sincronizados novamente. A me-
lhor maneira desativar o servidor ativo, sincronizar os arquivos do Post-
gresql via rsync, por exemplo, reiniciar os bancos e o PGpool.
O PGpool envia uma query para o master" que envia para o slave" antes
do master" completar a query. Isto pode aumentar a performance (desem-
penho) mas acrescenta o risco de deadlock". Para balancear performance e
risco, PGpool pode operar de duas formas:
1) modo restrict": Neste modo, PGpool espera a concluso da query no n

master para depois envia-la para o secundrio. Este o modo de opera-
o padro e mais seguro do PGpool.
2) palavra chave /*STRICT*/: Visando performance, o modo restrict
pode ser desabilitado atravs do ajuste da diretiva PGpool_restrict"na
configurao do PGpool. Para inibir deadlocks, deve-se inserir a
/*STRICT*/ no inicio de cada query passvel de produzir deadlock,
como por exemplo:
/*STRICT*/ LOCK TABLE t1;
Caso algum deadlock ocorra, no sendo detectado pelo prprio Post-

greSQL, PGpool abortar a sesso se um dos ns no responderem por um
certo intervalo de tempo configurvel.
Para propsitos de balanceamento de carga (configurvel pelo parme-

tro load_balance_mode" no arquivo de configurao), as consultas SE-
LECT"so distribudas entre o n master e o slave de maneira aleatria, para
aumentar performance.
importante notar que mesmo instrues SELECTpodem introduzir al-

teraes em bancos chamando funes que podem modific-los. Em casos
como este no se deve usar o balancemanto de carga, sendo necessrio se
usar espaos em branco antes da query para que ela no seja distribuda.
Eis uma lista de vantagens no uso do PGpool:
. No necessrio modificaes na aplicao.

. Qualquer linguagem pode ser usada.
. O nmero de conexes com o PostgreSQL pode ser limitado.

G UIA DE C LUSTER 9.3.1 - PG POOL
. Tolerncia a falhas. Caso ocorra falha em um servidor PostgreSQL, o outro

assume automaticamente.
. Replicao.
. Balanceamento de carga, consultas somente leitura podem ser distribu-

das entre os servidores.
Desvantagens:
. Sobrecarga. Todos os acessos ao PostgreSQL passam pelo PGpool o que

pode reduzir um pouco a performance (de 1 a 15%, de acordo com os
desenvolvedores, em testes feitos com pgbench).
. Nem todos protocolos da libpq so suportados:
1 Nenhum mtodo de autenticao exceto trust"e clear text pas-

sword"em modo de replicao.
2 Em modo no replicado s so aceitos trust", clear text password",
crypt"e md5".
3 Controle de acesso via pg_hba.conf no suportado.
. Sem controle de acesso, qualquer um pode acessar PGpool, o que pode

ser impedido via iptables, por exemplo.
PGpool-II
PGpool-II um projeto que herdou as caractersticas do PGpool, mas que

suporta mltiplas instncias do PostgreSQL (128 ns, expansvel via recom-
pilao do cdigo-fonte) e processamento paralelo nos mltiplos ns, o que
aumenta muito a performance.
A arquitetura do PGpool-II consiste, em um System DB" que processa as

informaes administrativas e operaes agregadas, e mltiplos ns onde
so armazenados os dados. Novos dados sero includos/alterados no n
DB baseado em regras de particionamento pr-definido. Uma regra de par-
ticionamento definida por funes SQL e so armazenadas no System
DB", que outro servidor PosgreSQL. A arquitetura do PGpool-II ilus-
trada na figura 9.1 que se segue.

G UIA DE C LUSTER 9.3.2 - PG CLUSTER
Figura 9.1: Arquitetura PG-pool
9.3.2 PGcluster
PGCluster[17] um conjunto de modificaes para o cdigo fonte do Post-

greSQL que permite a montagem de um sistema de replicao sncrono
multi-master, garantindo replicao consistente e balanceamento de carga
para bancos de dados baseados em PostgreSQL. A replicao sncrona ga-
rante que dados sejam replicados sem que haja atraso e a caracterstica de
ser multi-master permite que dois ou mais ns de armazenamento possam
receber requisies de usurios ao mesmo tempo.
O sistema composto por trs tipos de mquinas:
. servidor de balanceamento (Load Balancer): recebe consultas e as enca-

minha para os ns de armazenamento. As consultas so distribudas de
acordo com a carga de cada n. Podendo existir mais de um balanceador
de carga.
. servidor de armazenamento (Cluster DB): mquina que recebe e arma-

zena as consultas em bancos de dados.
. servidor de replicao (Replicator): cuida de manter os dados sincroni-

zados entre os servidores. Mais de um servidor pode ser utilizado, neste
caso, outro servidor s assume se o servidor de replicao principal falhar.
O sistema cumpre as seguintes funes:

. Balanceamento de carga: Pela combinao de servidores de armazena-

mento e servidor de replicao, pode-se criar um sistema onde o PGClus-
ter verificar qual mquina est com menor carga, redirecionando uma
possvel consulta para ela.
. Alta disponibilidade: Com a adio de um balanceador de carga, PG-

Cluster configura um sistema de alta disponibilidade. O balanceador de
carga e o servidor de replicao separar um n que ocasionalmente falhe
e continuar a servir com o restante do sistema. Assim que a mquina
que falhou for reestabelecida ao sistema, os dados sero copiados para
ela automaticamente, o mesmo acontece com um novo n que venha a se
integrar ao sistema.
Sistema de Balanceamento de Carga Combinando os servidores de ar-

mazenamento e servidor de replicao, PGCluster pode distribuir carga de
acesso ao banco de dados, verificando qual mquina est com menor carga,
redirecionando consultas para ela. A figura 9.2 ilustra a estrutura de balan-
ceamento de carga.
Figura 9.2: Sistema de balanceamento de carga
Sistema de Alta disponibilidade Adicionalmente, PGCluster pode pro-

ver um sistema de Alta Disponibilidade pela adio de um balanceador de

carga. Quando uma falha ocorre em um servidor de armazenamento, os

servidores de balanceamento e de replicao separam o componente falho
e continuam servindo com o restante do sistema. Isto feito sem que haja
interrupo do mesmo. A figura 9.3 ilustra a estrutura de Alta Disponibili-
dade para o PGcluster.
Quando uma mquina que falhou recolocada no sistema, os dados so
copiados para ela automaticamente, o mesmo acontecendo quando um ser-
vidor de armazenamento novo adicionado.
Figura 9.3: Sistema de alta disponibilidade

G UIA DE C LUSTER 9.3.3 - S LONY
9.3.3 Slony
Slony[7] um sistema de replicao master" para muitos slaves" que

suporta cascateamento e transformao de slaves" para master" , possui
capacidade para replicar grandes bancos de dados em at doze servidores
slave. O Slony foi criado para atender a data centers e stios de backup onde
todos os ns devem estar disponveis a qualquer momento.
H alguns modelos distintos de replicao de bancos de dados, difcil que
um modelo se adapte todas as necessidades. O modelo implementado
no Slony-I chamado de replicao assncrona usando triggers para coletar
as atualizaes, onde uma origem comum replicada em mltiplas cpias
incluindo cpias cascateadas.
Em algumas situaes, Slony no aconselhvel:
. Sistemas com conectividade ruim

. Replicao em ns com certa imprevisibilidade na conexo.
. Sistemas cuja configurao mude de maneira aleatria.
. Sistemas onde schemas de bancos de dados podem ser mudados arbitrari-
amente.
Slony um sistema de replicao independente de verso do PostgreSQL,

permitindo ser iniciado ou parado sem a necessidade de ciclos de dump/-
reload.
Dentre as coisas que Slony no :
. No um sistema de gerenciamento de rede.

. No possui nenhuma funcionalidade para detectar falha de n, nem muda
um n master para outro, embora isso possa ser conseguido em conjuno
com outras ferramentas.
. No um sistema de replicao multi-master, mas h planos para
transform-lo em multi-master na verso 2, muito embora seja um projeto
separado e ainda encontre-se em desenvolvimento.
Modelos de replicao H alguns modelos distintos de replicao de ban-

cos de dados, difcil que um modelo se adapte todas as necessidades.
O modelo implementado no Slony-I chamado de replicao assncrona

G UIA DE C LUSTER 9.4 - M YSQL
usando triggers para coletar as atualizaes, onde uma origem comum re-
plicada em mltiplas cpias incluindo cpias cascateadas.
Slony no propaga mudanas em schemas, nem replica grandes objetos.
Slony coleta as atualizaes com triggers, sendo que apenas tabelas e
seqencias so replicadas.
9.4 Mysql
O MySQL um servidor de bancos de dados SQL (Structured Query Lan-

guage - Linguagem Estruturada para Pesquisas) muito rpido, multi-tarefa
e multi-usurio. O Servidor MySQL pode ser usado em sistemas de pro-
duo com alta carga e misso crtica bem como pode ser embutido em
programa de uso em massa. MySQL uma marca registrada da MySQL AB
[13].
9.4.1 Replicao em MySQL
Uma das dificuldades no trabalho com grandes bancos de dados MySQL

a manuteno de backup seguro sem a necessidade do desligamento do
sistema. Um backup online, poderia deixar o sistema lento alm de cau-
sar inconsistncias de dados, j que tabelas podem estar sendo modificadas
enquanto o backup feito. O problema de inconsistncia poderia ser resol-
vido com a paralizao do banco, entretanto deixaria os usurios do sistema
sem acesso ao servio. O backup de fato uma medida necessria, mas a
paralizao diria do sistema inaceitvel. Um mtodo alternativo simples
para se assegurar backups confiveis mantendo disponvel o sistema a
replicao do MySQL.
A replicao uma configurao onde um servidor MySQL, conhecido
neste contexto como master, armazena dados e gerencia as conexes dos cli-
entes enquanto outro (ou outros) servidores mantm uma cpia completa
dos dados do master, duplicando as consultas SQL executadas no master
logo que elas aconteem.
O sistema de replicao MySQL permite que mltiplos servidores slave
mantenham seus dados sincronizados com um nico servidor master. En-
tre as vantagens da replicao esto a facilidade de backup e recuperao,
alm de dar melhor suporte a grandes aplicaes. possvel se conseguir

G UIA DE C LUSTER 9.4.1 - R EPLICAO EM M Y SQL
escabilidade linear enviando as requisies de escrita (INSERT, UPDATE,

DELETE) para o servidor master e as conexes de leitura (SELECT) para os
servidores slave.
Replicao oferece robustez, velocidade e vantagens administrativas:
. A robustez incrementada com uma configurao master/slave, caso

ocorra algum problema com o master, um slave pode assumir seu lugar.
. Melhora no tempo de resposta aos clientes pode ser conseguida dividindo
a carga para o processamento das consultas do clientes entre master e sla-
ves. As consultas SELECT podem ser enviadas aos slaves para reduzir
a carga do processamento de consultas no master. Declaraes que im-
pliquem em modificaes devem ser enviadas ao master para manter os
dados sincronizados.
. Outro benefcio do uso da replicao que backups de bancos de dados
podem ser realizados sem interromper o master. O master continua os pro-
cessos de atualizao enquanto o backup feito.
O Processo de Replicao
Quando o sistema de replicao esta sendo utilizado, quaisquer declaraes

SQL so executadas no servidor master. MySQL grava estas declaraes em
um log binrio (bin.log) juntamente com um nmero que identifica sua po-
sio no log. O servidor slave, com certa freqncia, verifica este log em
busca de mudanas. Se uma mudana encontrada, o slave a copia para seu
log de vigilncia (relay.log). Alm disso, o slave grava um novo nmero de
identificao posicional em um arquivo (master.info). O slave, ento, volta a
verificar o master, quando alguma alterao encontrada ela executada e
gravada no relay.log. Como salvaguarda, atravs de uma thread SQL o slave
compara seus dados com os dados do master. Se a comparao se mostrar
inconsistente, o processo de replicao para e uma mensagem de erro gra-
vada no log de erro do slave (error.log). Se o resultado for satisfatrio (os
dados estiverem corretos), um novo nmero de identificao de log gra-
vado no relay-log.info e o slave espera por outra mudana em seu arquivo
relay.log.
O processo parece complicado primeira vista, mas rpido e no ocupa
significativamente o master, alm de assegurar replicao confivel, sendo
tambm muito simples de configurar, significando algumas poucas linhas

G UIA DE C LUSTER 9.4.1 - R EPLICAO EM M Y SQL
adicionais ao arquivo de configurao do MySQL (my.cnf) em ambos os

servidores master e slave. Se o servidor slave novo, voc precisar de uma
cpia dos bancos de dados do master no slave para coloca-lo no ar. Ento o
problema se resumir a iniciar o servidor slave para comear a replicao.
Viso geral da implementao da replicao
A replicao em MySQL baseada no log binrio das alteraes feitas nos

bancos de dados do servidor master. Cada servidor slave recebe do master
as alteraes salvas que foram gravadas executando-as em seu conjunto de
dados.
importante frisar que o log binrio simplesmente uma gravao come-
ando de um ponto fixo a partir do momento em que este log foi habilitado
no servidor. Qualquer slave precisar de cpias das bases de dados do mas-
ter exatamente como existiam no momento em que o log binrio foi iniciado,
de outra forma a replicao falhar.
Aps ser configurado, o servidor slave conecta ao master e espera por atua-
lizaes. Se o master cair ou a conexo for perdida, o slave continuar ten-
tando se conectar periodicamente at que seja capaz de receber informaes
sobre modificaes. O intervalo padro 60 segundos.
Replicao baseada em coluna
A propagao de declarao SQL do master para o slave o princpio original

da replicao em MySQL. Isto chamado replicao baseada em declarao.
A partir da verso MySQL 5.1.5, outro modelo passou a estar disponvel, a
chamada replicao baseada em coluna. Ao invs de enviar as declaraes
MySQL para o slave, o master escreve os eventos em um log binrio indi-
cando como as colunas individuais das tabelas foram afetadas. A verso
5.1.8 oferece uma terceira opo: a mista, que usa replicao baseada em
declarao por padro e a baseada em coluna em casos particulares.
Adicionalmente mudana automtica do formato de log, um servidor
slave pode mudar o formato automaticamente. Isto acontece quando um
servidor est rodando em modo STATEMENT ou MIXED e encontra uma
coluna no log binrio que foi escrita em formato ROW. Neste caso, o slave
muda para modo de replicao coluna temporariamente para este evento,
voltando para o modo prvio logo aps.

G UIA DE C LUSTER 9.4.2 - M Y SQL C LUSTER
H duas razes para se ajustar o log de replicao baseado na conexo:
. Com uma thread que faz pequenas modificaes no banco de dados pre-
fervel usar log baseado em coluna. Uma thread que realiza updates em
vrias colunas com uma clusula WHERE deve usar log baseado em decla-
rao por ser mais eficiente gravar no log poucas declaraes que muitas
colunas.
. Algumas declaraes requerem muito tempo de execuo no master, mas
resultam em poucas colunas modificadas. Deve ento, ser benfico
replic-las utilizando-se log baseado em coluna.
H algumas excees para as quais no se pode mudar o modo de replica-

o em tempo de execuo:
. Funes armazenadas e trigger.

. Se o NDB estiver habilitado.
. Se sesso aberta em modo de replicao em coluna e tabelas estiver tem-
porariamente aberta.
No recomendado mudar o modo de replicao em tempo de execuo

enquanto tabelas temporrias existirem, porque estas tabelas so gravadas
no log apenas com replicao baseada em declarao, com replicao base-
ada em coluna elas no sero gravadas no log. Com replicao mista, tabe-
las temporrias so usualmente gravadas no log, excees para os casos de
funes definidas pelo usurio (UDF) e a funo UUID().
9.4.2 MySQL Cluster
MySQL cluster tecnologia que habilita clusterizao de bancos de da-

dos em memria sem dependncia de hardware ou tecnologia especfica.
MySQL Cluster implementa uma arquitetura distribuda, altamente tole-
rante a falhas com nenhum ponto nico de falha (SPOF), recuperao au-
tomtica de ns garantindo a confiabilidade de um mainframe em hardware
de baixo custo, constituindo uma soluo de alta disponibilidade com exce-
lente custo benefcio.
O sistema integra um servidor MySQL padro com componente para ar-
mazenamento clusterizado em memria chamado NDB, consistindo de

G UIA DE C LUSTER 9.5 - Middlewares INDEPENDENTES DE B ANCO DE D ADOS
um conjunto de computadores rodando processos que incluem servidores

MySQL, ns de dados para o cluster NDB, servidores de gerenciamento e
programas especializados para acesso a dados.
A engine de armazenamento NDB pode ser configurada com muitas opes
de tolerncia a falhas e balanceamento de carga. Cada parte do MySQL clus-
ter configurada independentemente dos servidores MySQL, sendo que
cada parte considerada um n1 .
H trs tipos de ns e em uma configurao mnima de um cluster MySQL
exige um de cada tipo:
. N de gerenciamento: Sua funo gerenciar os outros ns do cluster

exercendo funes como prover dados de configurao, iniciar e parar
outros ns, backup entre outras coisas. Deve ser o primeiro a ser inici-
ado pois gerencia a configurao dos outros ns.
. N de dados: Este tipo de n armazena os dados do cluster. H tantos ns
de dados quantas rplicas multiplicado pelo nmero de fragmentos2 .
. N SQL: Este n acessa os dados do cluster. um servidor MySQL tradi-
cional que usa a engine de armazenamento NDB.
Num ambiente real de produo, a configurao com trs ns no inclui

redundncia. Para se beneficiar das propriedades de alta disponibilidade
do MySQL Cluster recomendvel se usar mltiplos ns de gerenciamento,
de dados e de SQL.
9.5 Middlewares independentes de Banco de Dados
9.5.1 Middleware Sequoia
Os dados aqui apresentados sobre o Sequoia tem como referncia a documen-

tao User Guide" traduzida pela equipe do Ministrio do Planejamento, que
1
Em muitos contextos um n geralmente uma mquina, mas em MySQL cluster n um
processo, sendo possvel rodar qualquer nmero de ns em uma nica mquina
2
No contexto do MySQL Cluster, fragmento uma parte de um banco de dados, uma tabela
dividida entre vrios ns para facilitar balanceamento de carga entre as mquinas e ns. Cada
fragmento armazenado como rplicas em outros ns para prover redundncia.

G UIA DE C LUSTER 9.5.1 - M IDDLEWARE S EQUOIA
pode ser obtida no endereo http://guialivre.governoeletronico.gov.br/

guiacluster/
O que Sequoia
O Sequoia um middleware de cluster que permite que qualquer aplicao

JavaTM (aplicao standalone, servlet ou container EJBTM ) acessar, transparente-
mente, um cluster de banco de dados atravs de JDBCTM . No necessrio reali-
zar modificaes nas aplicaes clientes, nas aplicaes servidoras ou no servidor
de banco de dados. Basta apenas que os banco de dados sejam acessados pelo Se-
quoia.
O Sequoia um projeto livre de cdigo aberto, continuao do projeto C-JDBC

(http://c-jdbc.obejctweb.org) hospedado pelo projeto ObjectWeb Con-
sortium (http://www.objectweb.org). Sequoia liberado sob a licena
Apache v2 (www.apache.org/licenses/LICENSE-2.0.html) enquanto C-
JDBC liberado sob a licena GNU Lesser General Public License (http://www.
gnu.org/copyleft/lesser.html)
(LGPL).
O Sequoia tambm prov um driver para aplicaes no escritas em Java. O de-

senvolvimento do driver est na pgina do projeto Carob (carob.continuent.
org). Um plug-in Eclipse para o Sequoia est disponvel na pgina do projeto
Oak (oak.continuent.org).
O que eu preciso para usar Sequoia
Para se usar Sequoia, necessrio o que se segue:
. uma aplicao cliente que acesse um banco de dados atravs de JDBC.
. uma mquina virtual JavaTM compilada para JDKTM 1.4(ou mais recente)3 .
3
Sequoia pode funcionar com verses mais antigas da mquina virtual, mas no foi testado.

. um banco de dados com driver JDBC(tipo 1, 2, 3 ou 4) ou um driver ODBC

para ser usado com JDBC-ODBC bridge.
. comunicao de rede com suporte a TCP/IP entre os ns do cluster.
Nota: Se sua aplicao cliente no suporta JDBC, voc pode usar a API C++ ou o driver
ODBC disponibilizado pelo projeto Carob (http://carob.continuent.org)
Porque devo usar Sequoia
Se voc tem uma aplicao cliente em Java ou uma aplicao de servidor baseada
em Java que acessa um ou mais bancos de dados, a fila do banco de dados torna-
se um gargalo para sua aplicao ou um ponto nico de falha ou ambas as coisas.
O Sequoia pode ajudar a resolver este problema provendo:
. Escalabilidade de performance pela adio de ns de banco de dados e balan-

eamento de carga entre os ns.
. Alta disponibilidade para o banco de dados: se ocorrer problemas com os ns,

O Sequoia oferece tolerncia a falhas de maneira transparente usando tcnicas
de replicao.
. Incrementa performance com cache de consultas de granulosidade fina e pool

de conexo transparente.
. Log de trfego SQL para monitoramento e anlise de performance.
. Suporte para cluster de bancos heterogneos.
Como funciona
O Sequoia prov arquitetura flexvel que permite alcanar escalabilidade, alta

disponibilidade e tolerncia a falhas para banco de dados, atravs do conceito
de RAIDb:Array Redundante no-oneroso de banco de dados (Redundant Array
of Inexpensive Databases). O banco de dados distribudo e replicado entre vrios
ns e o Sequoia responsvel por distribuir a carga das consultas entre eles.

O Sequoia dispe de um driver JDBC genrico para ser usado pelos clientes.
Este driver repassa as requisies para o controlador que faz o balanceamento do
cluster de banco de dados (leituras so balanceadas e escritas so difundidas).
Podendo ser utilizado qualquer SGBD ( Sistema de Gerenciamento de Bancos
de Dados Relacionais - Relational DataBase Management System) que possua um
driver JDBC, isto valido para todos os bancos de dados em Cdigo Aberto e
Comerciais existentes.
Figura 9.4: Princpio do Sequoia
A arquitetura completamente aberta permitindo que qualquer um adicione cus-

tomizaes como agendadores de requisies, balanceadores de carga, gerencia-
dores de conexo, polticas de caching, entre outras.
Qual o custo
Sob o ponto de vista de software, O Sequoia um software de cdigo aberto

licenciado sob a Licena Apache v2 significando que seu uso (pessoal ou co-
mercial) livre de qualquer taxa. Se voc estiver usando um SGBD comercial
(Oracle,DB2,...), haver os custos das licenas adicionais para ns extras nos

quais voc instalar rplicas de seu banco. Mas possvel o uso de bancos de
cdigo aberto para hospedar rplicas de seu banco de dados principal.
Mquinas extras so necessrias para maior performance e maior tolerncia a

falhas. Sendo que o Sequoia foi desenhado para trabalhar com mquinas de baixo
custo pois estas so os primeiros alvos de solues em cdigo aberto de baixo
custo, mas ele funciona igualmente bem em grandes mquinas SMP. Uma placa
de rede comum suficiente para uma boa performance.
Quais modificaes so necessrias
Voc no necessita de qualquer mudana em sua aplicao ou seu banco de dados.
necessria, apenas, a atualizao da configurao do driver JDBC usado por

sua aplicao (usualmente apenas a atualizao de um arquivo de configurao)
e os ajustes no arquivo de configurao do Sequoia.
RAIDb bsico
A equipe de desenvolvimento do C-JDBC (antigo nome do projeto Sequoia) criou

e implementou o conceito de RAIDb. RAIDb est para bancos de dados assim
como RAID est para discos. RAID combina vrios discos rgidos de baixo custo
em um array de discos para obter performance, capacidade e confiabilidade que
excedem as capacidades de um disco de grande capacidade. RAIDb visa me-
lhor performance e tolerncia a falhas pela combinao de mltiplas instncias
de bancos de dados em um array de bancos de dados.
RAIDb objetiva o uso de hardware e software de baixo custo como cluster de works-
tations e bancos de dados de cdigo aberto. Clusters de workstations j so alter-
nativa vivel se comparadas s mquinas paralelas usadas em pesquisa cientfica
pela vantajosa relao custo/beneficio. Clusters desta natureza podem ser usa-
dos para prover alta disponibilidade e escalabilidade em ambientes de bancos de
dados.
RAIDb esconde a complexidade da replicao disponibilizando ao cliente atra-

vs da viso de acesso a um nico banco de dados, utilizando-se uma mquina

(controller) que colocada frente dos recursos disponveis. Os cliente direcio-
nam suas requisies ao controlador RAIDb que por sua vez as distribui ao seu
conjunto de sistemas de gerenciamento de bancos de dados (SGBD).
Os trs nveis bsicos do RAIDb so:
. RAIDb-0: que particiona o banco de dados entre os ns mas no oferece tole-

rncia a falhas.
. RAIDb-1: para replicao e espelhamento completo.
. RAIDb-2: que oferece replicao parcial.
Tambm esto definidos, RAIDb-1ec e RAIDb-2ec que adicionam verificao de

erros aos nveis RAIDb-1 e RAIDb-2, respectivamente.
RAIDb-0: Com este nvel de RAIDb pode-se particionar o banco de dados, dis-
tribuindo suas tabelas entre os backends (mquina que hospeda o banco). Uma
tabela em si no pode ser particionada, mas tabelas diferentes podem estar em
diferentes ns. Esta configurao requer no mnimo dois backends, provendo es-
calabilidade de performance mas sem tolerncia a falhas.
A figura 9.5 mostra um exemplo de configurao RAIDb-0.
Figura 9.5: Exemplo de RAIDb-0

RAIDb-1 RAIDb-1 oferece espelhamento completo com replicao total dos

bancos de dados nos backends. Este modelo de configurao o que apresenta
melhor tolerncia a falhas j que o sistema ainda estar disponvel se apenas um
n estiver ativo. A desvantagem que no h melhoria nos processos de escrita
em banco (UPDATE, INSERT, DELETE) j que todos estes tipos de requisies
sero enviadas para todos os ns. Para assegurar integridade, RAIDb-1ec realiza
verificao de erros ao RAIDb-1, objetivando deteco de erros bizarros. Reque-
rendo ao menos 3 ns, esta configurao envia as requisies de escrita para a
maioria dos ns que compem o cluster e as resposta so comparadas. Se h con-
senso nas respostas, elas so enviadas aos clientes, caso contrrio uma mensagem
de erro enviada em resposta a requisio.
A figura 9.6 mostra um exemplo da configurao RAIDb-1.
RAIDb-2 RAIDb-2 a combinao de RAIDb-0 e RAIDb-1, provendo replica-

o parcial para diminuir a degradao no processo de replicao de cada tabela
do banco de dados e obtendo melhores resultados de leitura e escrita. Este mo-
delo requer que cada tabela esteja disponvel em pelo menos 2 ns.
Tambm implementa verificao de erro como RAIDb-1ec. Opera com um m-

nimo de 4 ns sendo que 3 deles configuram quorum para resposta. A escolha
dos ns tambm mais complexa que em RAIDb-1ec dada a possibilidade de re-
plicao parcial, embora esta caracterstica garanta uma melhor performance. A
figura 9.7 mostra um exemplo desta configurao.

Nveis de RAIDb aninhados possvel utilizar vrios nveis de RAIDb ao

mesmo tempo para se configurar grandes sistemas ou atender necessidades es-
pecficas. Um controlador RAIDb escala um nmero limitado de bancos de da-
dos, entretanto pode-se cascatear vrios controladores para disponibilizar mais
backends. Em princpio, no h limite para a profundidade do aninhamento de
RAIDb. RAIDb de mesmo nvel podem ser aninhados como por exemplo um sis-
tema com RAIDb-1-1 para espelhamento de vrios bancos de dados. Para evitar
que o controlador se torne um ponto nico de falha, dois ou mais controlado-
res podem ser usados para atender s requisies. O middleware de comunicao
de grupo JGroups usado para sincronizar as modificaes nos bancos de ma-
neira distribuda. Os bancos de dados no necessitam ser compartilhados entre
os controladores, mas caso um controlador caia, os bancos associados a ele tam-
bm ficaro indisponveis. No caso de backends compartilhados, um controlador
enviar as requisies aos backends informando ao outro controlador assim que
as requisies estiverem completadas.
A figura9.8. mostra um exemplo de uma configurao RAIDb-1-0.
O ltimo exemplo (figura 9.9) mostra uma composio RAIDb-0-1. O nvel mais
alto um controlador RAIDb-0 e a tolerncia a falhas conseguida graas a cada
partio usando controlador RAIDb-1.

Figura 9.8: Exemplo de RAIDb-1-0
Figura 9.9: Exemplo de RAIDb-0-1
Balanceamento de carga
O balanceador de carga define a maneira que as requisies sero distribudas

entre os backends de acordo com o nvel do RAIDb. possvel reforar um nvel
de isolamento especfico para todas as conexes (isto no ter efeito se o banco de
dados usado no suporta isolamento de transaes). Em geral, o nvel de isola-
mento de transao padro ser usado e nenhum reforo ser dado s conexes.
Os seguintes balanceadores de carga esto disponveis:
. SingleDB: balanceador de carga para um instncia nica de banco de dados.

G UIA DE C LUSTER 9.5.2 - PAR GRES
Disponvel se apenas um controlador for usado.
. ParallelDB: balanceador de carga para ser usado em banco de dados para-

lelos, como Oracle Parallel Server ou Middle-R. Ambas, escrita e leitura, so
balanceadas entre os backends, deixando a replicao paralela dos bancos escre-
ver.
. RAIDb-0: particionamento completo de banco de dados (nenhuma tabela

pode ser replicada) com poltica opcional que especfica onde novas tabelas se-
ro criadas.
. RAIDb-1: espelhamento completo de banco de dados (todas as tabelas so

replicadas em qualquer lugar) com poltica opcional que especfica como a con-
sumao de consultas distribudas (write/commit/rollback) so manipuladas
(quando o primeiro, a maioria ou todos os backends completam as consultas).
. RAIDb-1ec: espelhamento completo de banco de dados, como em RAIDb-1,

mais verificao de erros para deteco de falhas bizarras.
. RAIDb-2: replicao parcial (cada tabela deve ser replicada pelo menos 1 vez)
com polticas opcionais para criao de novas tabelas (como RAIDb-0) e con-
sumo de consultas distribudas (como em RAIDb-1).
. RAIDb-2ec: replicao parcial (como RAIDb-2) com verificao de deteco

de erros bizarros.
9.5.2 ParGRES
ParGRES[268] um projeto que tem como objetivo desenvolver um sistema em

software livre para processar com eficincia consultas pesadas que envolvam gran-
des quantidades de dados, usando para isso, o SGBD PostgreSQL sobre clusters
de PCs. No ParGRES, o processamento da consulta explora o paralelismo intra-
e inter-consultas, usando replicao e fragmentao virtual de dados.
O paralelismo do ParGRES voltado para as consultas pesadas tpicas de aplica-

es OLAP e proposta uma soluo para essa demanda atravs da implemen-
tao de paralelismo intra-consulta em um cluster de Banco de Dados. O para-
lelismo intra-consulta significa decompor consultas complexas em sub-consultas
que sero executadas em paralelo. A idia que cada sub-consulta atue em um

G UIA DE C LUSTER 9.5.2 - PAR GRES
fragmento de dados diferente. Dessa forma, cada sub-consulta poder ento ser
enviada para o n que possui o respectivo fragmento dos dados. Assim, cada
sub-consulta enviada para um n diferente e executada em paralelo com as
demais. Embora o desenvolvimento tenha sido realizado sobre o PostgreSQL, o
paralelismo baseado no padro SQL, no sendo dependente de nenhuma carac-
terstica especfica do SGBD (vide [16]).
Como as demais solues para clusters de bancos de dados, o ParGRES consiste

em uma camada intermediria de software (middleware) que orquestra instncias
de SGBDs em execuo nos diferentes ns do cluster para a implementao de
tcnicas de processamento paralelo.

Captulo 10
Alta Capacidade de Processamento -

HPC
Cluster de Processamento de alto desempenho (HPC - High Performace Cluster),

essa categoria de cluster possui como principal caracterstica o processamento de
alta performance/desempenho, grandes usurios dessa tecnologia no brasil so:
Universidades, centros de pesquisa, INPE, Petrobras.
10.1 Beowulf
Beowulf o nome de um projeto de cluster de computadores para computao

paralela, usando computadores pessoais, no especializados e portanto mais ba-
ratos. O projeto foi criado por Donald Becker 1 da NASA, e hoje so usados em
todo mundo, principalmente para programao cientfica.
Um cluster de Beowulf um grupo de computadores, normalmente PCs idnticos

que executam como sistema operacional o GNU/Linux ou BSD. Eles trabalham
em uma rede LAN TCP/IP pequena, e tem bibliotecas e programas instalados
que permitem o compartilhamento do processamento entre eles, mais informa-
es sobre essas bibliotecas e ferramentas podem ser obtidas na sesso 11.1.
1
Mais informaes sobre Donald Becker podem ser encontradas na WikiPedia http://en.
wikipedia.org/wiki/Donald_Becker

G UIA DE C LUSTER 10.2 - S ISTEMA DE I MAGEM NICA - SSI
No existe nenhum software, ou a utilizao de algum software, em particular que

defina um cluster como cluster Beowulf. Existem bibliotecas de processamento
paralelo que geralmente so usadas no cluster Beowulf, essas bibliotecas incluem:
MPI[305] (Message Passing Interface) e PVM[307] (Parallel Virtual Machine). Ambos
permitem o programador dividir uma tarefa entre um grupo de computadores
conectados em rede, e recolher os resultados das tarefas processadas.
Assim o nome Beowulf acaba sendo a descrio de ambientes de clusters de pro-

cessamento paralelo freqentemente encontrado. Existem vrias distribuies
e solues em software livre e aberto para esses ambientes. Pode-se citar como
exemplos de solues desenvolvidas para a criao de ambientes Beowulf : Oscar,
Rocks, Xcat (citadas na sesso 4.3.1).
Alm das solues que facilitam a instalao e configurao deste ambiente exis-
tem outras ferramentas de suporte, como ferramentas para o monitoramento,
controle e execuo de tarefas nos ns.
10.2 Sistema de Imagem nica - SSI
Sistema de Imagem nica (SSI) so mtodos utilizados para se esconder com-

plexidade dos sistemas distribudos, permitindo que os mesmos paream uma
nica mquina ao usurio. Logo desta maneira os fatores como a heterogenei-
dade do hardware implementado no ser problema para o seu funcionamento, e
questes como a gerncia e utilizao efetiva dos recursos sero facilmente solu-
cionadas. Conseguindo assim a viso de uma mquina nica, da mesma maneira
que uma mquina SMP s que na verdade utilizando-se de um ambiente de rede
distribudo, construdos de vrias mquinas. [101].
Em clusters, o SSI auxilia tanto na escalabilidade quanto na disponibilidade. Os

recursos de um cluster SSI so a soma dos recursos disponveis no cluster. Assim
o sistema visto como um nico recurso, a adio ou subtrao de alguns desses
recursos no afeta potencialmente o funcionamento do cluster, permitindo mui-
tas vezes, um incremento de recursos em tempo de execuo, dependendo da
escalabilidade suportada. Pode tambm assegurar que o sistema continue fun-
cionando aps alguma falha em um ou alguns de seus ns sem que haja perdas

G UIA DE C LUSTER 10.2.1 - A S P RINCIPAIS C ARACTERSTICAS DE UM C LUSTER SSI
considerveis, permitindo que o cluster fique sempre disponvel para as aplica-

es do usurio.
A visualizao dos ns como um SSI permite a monitorao centralizada dos

recursos de cada um deles, tornando-se possvel um balanceamento de carga efe-
tivo, dividindo os processos entre os ns da melhor maneira fazendo com que os
recursos sejam bem utilizados. Permite tambm uma hierarquia globalizada com
mltiplos sistemas de arquivos e espao nico de memria e de dispositivos de
entrada e sada, alm de um endereamento global para os processos.
Embora a implementao do SSI ainda seja muito limitada nos clusters, j apre-
senta vrios benefcios, e que esto evoluindo a todo o momento, permitindo um
incremento tanto da escalabilidade quanto do sistema de imagem nica, podendo
se gerar uma estrutura cada vez mais prxima da estrutura SMP, s que com
uma excelente escalabilidade. O SSI pode ser implementado atravs de hardware,
multiprocessadores ( ver 6.1.2), ou por software, este ltimo geralmente feito
utilizando-se de uma camada de middleware ou uma camada adicional (patch) ao
kernel [104].
O middleware composto de uma camada de infraestrutura de disponibilidade

que fica acima da camada do sistema operacional e por uma camada de infra-
estrutura de imagem nica que fica logo acima da primeira, a camada de SSI
quem faz a interface com as aplicaes dos usurios. Todos os pacotes trabalham
em conjunto dando melhor suporte a essas camadas, providenciando tambm
uma eficiente implementao para DSM, checkpoint e migrao de processos.
10.2.1 As Principais Caractersticas de um Cluster SSI
A seguir esto descritas as principais caractersticas que um cluster deve possuir

para ser considerado um Sistema de Imagem nica, segundo Buyya [104]:
Ponto nico de acesso: garantia de transparncia ao usurio da mquina

ao qual o mesmo est se logando em meio a todos os ns do cluster. Desse
modo diferentes ns atendem diferentes usurios, dividindo a carga apre-
sentada pelas requisies de cada usurio de forma transparente ao mesmo.

G UIA DE C LUSTER 10.2.1 - A S P RINCIPAIS C ARACTERSTICAS DE UM C LUSTER SSI
Interface nica de usurio: os usurios devem acessar o cluster atravs de

uma nica interface grfica de usurio, tal como uma pgina web onde se
possam usufruir os servios associados ao cluster. Essa interface deve pos-
suir as mesmas caractersticas para todos os usurios.
Espao de processo nico: todos os processos, independemente do local

onde se encontrem, devem poder se comunicar com processos de quaisquer
ns; devem poder migrar para qualquer n e podem geram novos proces-
sos. Um cluster SSI deve permitir a administrao dos processos como se
estivessem sendo executados localmente, isto , deve-se garantir o controle
dos processos independentemente do local onde estejam sendo executados.
Espao de memria nico: deve-se garantir ao usurio a iluso de um es-

pao nico de memria, de forma que os diversos espaos locais dos in-
meros ns que compem o cluster fossem uma nica grande memria. Para
isso existem diferentes abordagens tais como o uso de software garantindo
uma camada acima da memria de cada n, simulando a existncia de um
nico espao de memria; o outro modo o desenvolvimento distribudo,
isto , implementao no prprio cdigo atravs do uso de bibliotecas tais
como MPI ou PVM, onde o compilador do sistema onde se executa a apli-
cao se encarrega de distribuir a estrutura dos dados entre os diversos ns
do cluster.
Espao de E/S nico: garantir a execuo de operaes de entrada/sada a

perifricos e discos tanto localmente quanto remotamente, de forma trans-
parente ao usurio. Fazendo assim um nico espao de endereamento for-
mado pelos diversos discos associados aos ns do cluster, RAIDs anexados
rede e um exemplo.
Hierarquia nica de arquivos: os usurios ao terem acesso ao sistema de

arquivos do cluster SSI devem possuir uma viso nica do mesmo, de modo
com que todos identifiquem os diversos discos, perifricos e diretrios sob
uma mesma raiz de uma nica forma. Exemplos de hierarquia nica para
um sistema de arquivos so o NFS, o MFS e o GFS.
Rede virtual nica: um n deve possuir a capacidade de acessar qualquer

conexo de rede atravs do domnio do cluster, mesmo que a rede no esteja
conectada a todos os ns do cluster.
Sistema de administrao de jobs nico: um job de um usurio pode ser

G UIA DE C LUSTER 10.2.2 - O S P RINCIPAIS B ENEFCIOS DE UM S ISTEMA SSI
submetido de qualquer n do cluster e pode requisitar quantos ns quiser

para execut-lo.
Ponto de controle e administrao nico: todo o cluster, isto , cada um dos

ns que o compe devem poder ser testados, configurados e monitorados
atravs de um nico conjunto de interfaces grficas tais como uma pgina
web.
Migrao de processos e checkpointing: deve-se fazer periodicamente a gra-

vao das informaes dos processos tais como estado e processo ou em
memria ou em disco, garantindo em caso de falha do mesmo sua continu-
ao em outro n. Alm disso devido necessidade de balanceamento de
carga deve-se garantir a migrao de processos entre os diversos pontos do
cluster.
10.2.2 Os Principais Benefcios de um Sistema SSI
Os principais benefcios que um sistema SSI proporciona ao funcionamento de

um cluster, segundo Buyya [104]:
Prov uma simples e nica viso de todos os recursos e atividades em exe-

cuo no cluster;
Exclui do usurio a necessidade de apontar onde se deve executar tal apli-

cao;
Garante o uso de recursos independentemente da proximidade fsica aos

mesmos;
Permite maior facilidade para gerenciamento do sistema pelo administra-

dor e uso do mesmo pelo usurio j que a interface e os comandos so um
s para o acesso a todos os ns;
Reduz a possibilidade de erros por parte do operador, por exemplo: utilizar

uma sintaxe de comandos diferentes para o acesso a um mesmo n, e outra
sintaxe diferente para um outro n. Desta maneira garantindo performance
e confiabilidade ao sistema;

G UIA DE C LUSTER 10.2.3 - M EMRIA D ISTRIBUDA C OMPARTILHADA - DSM
Como o controle deve ser apresentado de forma centralizada, o uso do sis-

tema por pessoas, sem que essas tenham elevado conhecimento sobre a ar-
quitetura deste, permite uma fcil utilizao por usurios comuns";
Reduo de gastos com a implantao/manuteno do sistema;
Prove comunicao de mensagens independente de localizao;
Como os programadores no devem se preocupar com a distribuio da

carga para suas aplicaes garante-se mais tempo aos mesmos para aumen-
tar a complexidade e qualidade de seus sistemas.
Promove a padronizao de ferramentas para o seu controle e administra-

o.
10.2.3 Memria Distribuda Compartilhada - DSM
Tcnica utilizada para compartilhamento de memria fsica dos ns, dando a ilu-
so de que o cluster possui uma nica e grande memria que formada pela
agregao das memrias de seus ns, implementando a abstrao de um espao
comum de endereamento agrupando as memrias isoladas em uma entidade l-
gica, podendo ser implementada por software ou hardware, permitindo a troca de
dados atravs de uma memria globalizada a todos os ns processadores [353].
Com essa tcnica, no h mais a necessidade de usar paradigmas de passagem

de mensagens explcitas como PVM ou MPI nos programas desenvolvidos es-
pecialmente para cluster, pois os programas que utilizam memria distribuda
compartilhada tm acesso as variveis em memria, da mesma forma como se
faz em variveis locais em sistemas onde no h memria compartilhada.
Cada processador tem uma viso de toda a memria, mas s tem acesso a parte
que destinada a ele, ento, caso ele queira acessar dados que no esto localiza-
dos na parte onde ele proprietrio, deve fazer uma cpia para sua rea, dando
origem a cpias mltiplas da mesma poro de dados da memria compartilhada
em diferentes memrias fsicas, tendo assim, que manter a coerncia destas c-
pias, permitindo que qualquer processador que acesse a memria compartilhada
devolva a informao correta, sendo a comunicao e a sincronizao feita atra-
vs da prpria memria.

G UIA DE C LUSTER 10.2.4 - O PEN M OSIX
Para se reduzir latncia de memria, ou seja, os tempos de acesso memria e

retorno da resposta, as caches privadas a cada processador so utilizadas, pois em
sistemas DSM h uma grande sobrecarga com a localizao dos dados e acesso
a memria distribuda, ficando esses caches com a funo de buffers temporrios,
para que no se desperdice ciclos do processador.
Quando um programa feito, existe uma ordem especifica de acesso a memria,

chamada consistncia seqencial. Num cluster essa consistncia invivel pois
os ns teriam que esperar a sua vez de acessar a memria para assim continuar
processando, isso geraria perda de desempenho e trfego excessivo na rede. Para
isso foram desenvolvidos modelos de consistncia que levam em considerao
que nem todos os ns processadores precisam naquele momento do contedo
atualizado.
Esses modelos implementam mtodos que tentam evitar ao mximo as condies

de corrida (race conditions), ou seja, acesso simultneo ao mesmo dado. Cada n
possui um mapeador de memria local onde ela particionada em blocos, sendo
a cache utilizada para reduzir a latncia de acesso memria remota e sendo a
memria principal dos ns um cache da DSM, formando assim uma hierarquia
simples de memria, ou seja, cada n enxerga sua memria local como uma cache
da DSM sendo cada bloco da memria a unidade bsica de cache.
10.2.4 OpenMosix
O openMosix um middleware para clustering open-source" que possui dois m-

dulos de grande valia ao servio de clustering: um patch para memria comparti-
lhada distribuda (migshm) e um mdulo para checkpointing.
Memria compartilhada usada na maior parte das aplicaes modernas, tais

como bancos de dados, servidores WEB, editores de texto, planilhas, e processa-
mento de imagens. A operao de compartilhamento de memria ajuda a facilitar
a troca de dados entre os processos.
Por exemplo, quando dois clientes fazem um select e um update em uma coluna
de uma tabela MySQL, o MySQL deve criar dois subprocessos e servir os coman-
dos SQL. Os processos forked" se anexam ao processo MySQL principal que

mantm os dados em memria. Usando esse esquema, no existe a necessidade

de se criar um data mirror e plug-lo de volta tabela real.
O benefcio que o servidor de banco de dados por reduzir a alocao de me-

mria. Evidentemente, um mecanismo de locking" necessrio para evitar um
deadlock" ou uma condio de corrida. Uma thread" uma verso leve de um
mecanismo fork( ). Ao invs de duplicar todo um segmento de memria de um
processo pai para um processo filho, o processo recm-criado apenas precisa ini-
cializar um pequeno segmento de dados e se anexar ao processo principal. Essa
tcnica (tambm chamada de LightWeight Process", ou LWP) oferece uma nova
maneira de multiprocessamento usando o mnimo possvel de memria. O apa-
che, servidor WEB, utiliza threads para aumentar a velocidade de suas tarefas de
forma a permitir aumentar o nmero de hits sem afetar sua performance.
O Migshm um patch DSM (Distributed Shared Memory) para o openMosix. Ele

permite a migrao de processos que utilizam memria compartilhada no open-
Mosix tais como o apache, entre outros.
Checkpointing" uma tcnica que prov a possibilidade de se salvar contex-

tos de processos em um arquivo de disco e dar um restore dos processos a partir
do arquivo. Logo processos que tenham sofrido checkpointing" e que sejam
reiniciados posteriormente deveriam funcionar como se no tivessem sido inter-
rompidos. Essa funcionalidade til para tarefas que possuam longos perodos
de execuo (como simulaes numricas) no caso de instabilidade de sistema,
falhas de energia, reinicializaes do sistema, etc. Checkpointing" costuma ser
um servio de sistemas operacionais avanados de clustering.
O CHPOX (Checkpointer for Linux) um mdulo do kernel Linux que prov

checkpointing" de processos. Ele foi criado por Olexander O. Sudakov e Eu-
geny S. Meshcheryakov no Information and Computing Center do National Ta-
ras Shevchenko University em Kyiv, Ucrnia. O CHPOX usa uma abordagem de
mdulo de kernel, logo ele pouco relacionado verso do kernel atual e di-
namicamente inserido e removido do espao de kernel. Devido sua integrao
com o Mosix/openMosix, o CHPOX se tornou rapidamente aceito pela comuni-
dade openMosix.
Tecnologia openMosix

O openMosix um conjunto de algoritmos para compartilhamento dinmico de

recursos que so utilizados para fornecer escalabilidade e performance em um
cluster CC (Cache Coherent) de qualquer tamanho, onde o nico componente com-
partilhado a rede. A idia principal da tecnologia do openMosix a capacidade
de mltiplos ns (workstations e servidores, incluindo SMPs) de trabalharem em
cooperao como parte de um sistema nico.
Com o sentido de compreender o que o openMosix faz, devemos comparar mul-

ticomputador de memria compartilhada (SMP) a um CC. Em um sistema SMP,
mltiplos processadores compartilham a memria. As principais vantagens so
o aumento do volume de processamento e a maior velocidade de comunicao
entre os processos(atravs da memria compartilhada). Mquinas SMP podem
suportar mltiplos processos trabalhando simultaneamente, com eficiente aloca-
o e compartilhamento de recursos. A qualquer momento que um processo seja
inicializado, finalizado, ou mude seu perfil computacional, o sistema se adapta
instantaneamente ao ambiente de execuo resultante. O usurio no envolvido
diretamente e, na maior parte dos casos, nem sabe da existncia de tais ativida-
des.
Ao contrrio do SMP, Clusters Computacionais (CC) so feitos de colees de

servidores (at mesmo SMPs) e workstations que fisicamente nada compartilham,
com diferentes velocidades e quantidades de memria, possivelmente de dife-
rentes geraes. Na maioria das vezes, CCs so utilizados para ambientes time-
sharing" e multiusurio. Em sistemas CC o usurio responsvel por alocar os
processos aos ns e a administrar os recursos do cluster. Em vrios sistemas CC,
mesmo estando todos os ns utilizando o mesmo sistema operacional, a coope-
rao entre os ns consideravelmente limitada pois a maioria dos servios do
sistema operacional so localmente confinadas ao n.
Os principais pacotes de software para alocao de processos em CCs so PVM

e MPI. Esses pacotes provem um ambiente de execuo que requer uma adap-
tao da aplicao e o conhecimento do usurio. Eles incluem ferramentas para
alocao inicial (fixa) de processos para ns, os quais algumas vezes utilizam con-
sideraes sobre a carga, enquanto ignoram a disponibilidade de outros recursos
tais como memria livre e overheads" de E/S. Esses pacotes ficam na camada
de usurio, assim como as aplicaes comuns, entretanto so incapazes de res-
ponder a mudanas no nvel de carga ou mesmo de outros recursos, ou at de

G UIA DE C LUSTER 10.2.5 - K ERRIGHED
redistribuir a carga do trabalho (job) de forma adaptativa.
Na prtica, o problema de alocao de recursos muito mais complexo pois exis-

tem vrios tipos diferentes de recursos, tais como CPU, memria, E/S, IPC (Co-
municao InterProcessos), etc, onde cada recurso utilizado de uma maneira
diferente e na maior parte das vezes seu uso imprevisvel. Outras dificuldades
surgem do fato que diferentes usurios no coordenam suas atividades. Entre-
tanto mesmo que um usurio saiba otimizar a alocao de recursos aos processos,
as atividades de outros usurios costumam interferir em sua otimizao.
Para o usurio, os sistemas SMP garantem eficincia, uso balanceado de recursos

entre os processos em execuo, independentemente dos requisitos de recurso.
SMPs so fceis de usar pois eles empregam administrao adaptativa de recur-
sos, o que completamente transparente ao usurio. Os atuais CCs no possuem
tais capacidades. Eles se baseiam na alocao esttica controlada pelo usurio, o
que inconveniente e pode levar a significativas perdas de performance devido
a cargas mal distribudas.
O openMosix um conjunto de algoritmos que juntos suportam compartilha-

mento adaptativo de recursos em um CC escalvel pela migrao dinmica de
processos. Ele pode ser visto como uma ferramenta que torna plataformas CC
mais prximas de ambientes SMP. Ao ter a capacidade de alocar recursos global-
mente, e distribuir o workload" dinamicamente e de forma eficiente acaba por
simplificar o uso de CCs ao tirar do usurio a responsabilidade de administrar os
recursos do cluster. Isso particularmente evidente em ambientes multi-usurios
e time-sharing", alm de CCs no uniformes.
10.2.5 Kerrighed
Kerrighed uma base operacional para sistemas de imagem nica (Single System
Image Operating System (SSI OS)) destinado para cluster construdos a partir de
PCs padres de mercado.
Um sistema operacional SSI d a iluso de uma mquina de SMP aos programas

que so executados em cima dele. Kerrighed uma extenso kernel do Linux.
No obstante, um cluster rodando Kerrighed no uma mquina de SMP real.

As metas do Kerrighed so alto desempenho de aplicaes, alta disponibilidade

do cluster, administrao de recursos eficientemente, alta poder de customizao
do sistema operacional e facilidade de uso.
Kerrighed implementado como uma extenso a sistema operacional GNU/Li-

nux (uma coleo de mdulos e um pequeno patch para o kernel Linux).
As principais caractersticas do Kerrighed so:
Escalonador customizvel para o cluster.

Processos e threads so automaticamente escalonados atravs dos ns do
cluster para balancear o uso de CPU atravs do escalonador padro do
Kerrighed. Porm, Kerrighed oferece um toolkit para escrever escalona-
dores sob encomenda com facilidade, que podem serem adicionados a
quente" nos mdulos do kernel.
Memria Compartilhada.
Threads e segmentos de memria do sistema podem ser operados atravs do
cluster, como em uma mquina SMP.
Mecanismos de migrao de fluxo de alta performance.

Podem ser migrados processos que usam fluxos (socket, pipe, fifo, char de-
vice, etc) sem penalidade no desempenho de comunicao depois de migra-
o.
Sistema de arquivo distribudo.

Um nico espao de nome de arquivo visto no cluster. Todos os discos
do cluster so fundidos em um nico disco virtual em um customizao
parecida como um RAID.
Verificao de processos.
Os processos podem ser verificados e reiniciados em qualquer n do cluster.
Interface de Thread Posix completa.

A interface de Thread Posix pode ser operada com threads espalhadas pelos
ns do cluster.
Interface de processos Unix visvel em todo o cluster.

Toda a interface tradicional de comandos de gerenciamento de processos

Unix (top, ps, kill, etc) so operados pelo cluster. Alm disso, os identifica-
dores de processos (pid) so nicos no cluster.
Caractersticas customizveis da imagem nica de sistema.

As caractersticas do SSI (memria compartilhada, escalonador global, mi-
grao de fluxos, etc) podem ser ativados ou no por base de processos.
Kerrighed no :
Um paralelizador automtico.
Kerrighed no paraleliza automaticamente suas aplicaes. Isso implica
que caso voc tenha um grande processo seqencial, ele no rodar mais
rpido no Kerrighed. Para rodar mais rpido, sua aplicao precisar ser
paralelizada. Se sua aplicao roda mais rapidamente em uma maquina
com vrios processadores do que em uma mquina com apenas um pro-
cessador, essa aplicao poder rodar mais rpido com o Kerrighed. Se a
aplicao no roda mais rpido em uma maquina com vrios processado-
res, ela no rodar mais rpido com o Kerrighed.
Um Middleware.
Kerrighed um sistema operacional, e no um middleware. Ele roda dentro
do kernel linux, e no em cima do kernel linux. Ele estende as funcionali-
dades do linux de gerenciamento de servios de cluster.
Uma mquina virtual.

Kerrighed no tem correlao nenhuma com tecnologias de virtualizao
como VMWare ou XEN. Ele no cria um cluster virtual, ele d a iluso que
um cluster fsico de PCs so uma mquina SMP nica.

Captulo 11
Ferramentas de Programao Paralela
11.1 Troca de Mensagens (Message Passing)
O paradigma de troca de mensagens tem sido tradicionalmente empregado em

sistemas fracamente acoplados, representados pelas arquiteturas baseadas em
memria distribuda (clusters), em que cada processador tem acesso somente
sua memria local e, por conseguinte, a comunicao, necessariamente, d-se por
meio de uma rede de interconexo.
Conceitualmente, a idia de troca de mensagens totalmente independente de

hardware, sistema operacional, linguagens de programao e bibliotecas. Quando
no desenvolvimento de um programa paralelo por troca de mensagens, o progra-
mador deve distribuir os dados explicitamente entre os processadores. Visto que
os espaos de endereamento dos processos que compem o programa paralelo
so distintos, concebeu-se a abstrao de mensagem, que pode ser enviada de um
processo a outro por um canal de comunicao. Tal conceito denotado no pro-
grama atravs de primitivas do tipo send e receive, as quais supem um processo
que pretende enviar (send) uma mensagem a outro, que espera receb-la (receive).
Entre os processos comunicantes diz-se que existe um canal de comunicao.
Na prtica, os programadores dispem de bibliotecas de comunicao com pri-

mitivas semelhana de send e receive. As bibliotecas de comunicao que obtive-
ram maior aceitao foram: MPI (Clarke [121]) e PVM (Geist [166]), ambas com

G UIA DE C LUSTER 11.1.1 - Parallel Virtual Machine - PVM
suporte s linguagens de programao C e Fortran.
11.1.1 Parallel Virtual Machine - PVM
O PVM[307] (Parallel Virtual Machine) um pacote de software que permite o fun-

cionamento de um conjunto de mquinas mono/multi-processadas e/ou parale-
las, como um nico recurso computacional paralelo. Com a utilizao do PVM
consegue-se uma forma eficiente e transparente de distribuir tarefas entre mqui-
nas ligadas em rede, conseguindo um bom desempenho na gerencia dos recursos
computacionais, atravs da configurao de uma mquina paralela virtual.
Caractersticas
O PVM habilita uma coleo de computadores heterogneos a se comportar como

um nico recurso computacional expansvel e concorrente, o que contribuiu para
torn-lo um padro de fato. um mecanismo de distribuio livre que oferece
bastante recursos para computao paralela com uma utilizao simples e de fcil
compreenso.
Algumas caractersticas do PVM so:
possibilita a atribuio das subtarefas de uma aplicao, de forma otimi-

zada, aos ns que compem o ambiente paralelo;
apresenta uma interface de programao intuitiva e consistente;
oferece suporte para tolerncia falhas, monitorao e profiling e
altamente portvel".
Com isso, atravs da agregao e compartilhamento de processadores e mem-

rias de computadores heterogneos, problemas que exigem grande poder com-
putacional podem ser resolvidos sem a necessidade de comprar um supercom-
putador. Assim, utilizar o PVM uma forma de aumentar o desempenho, com
um custo efetivo menor.

G UIA DE C LUSTER 11.1.2 - Message Passing Interface - MPI
Funcionamento Bsico .
O PVM composto de duas partes. A primeira parte um daemon, chamado

pvmd3, que executado em todos os computadores que vo formar a mquina
virtual paralela (MORETTI[278]). Esse programa roda em background em cada um
dos ns formando a maquina virtual, sendo responsvel pela troca de mensagens
entre eles alm da coordenao das tarefas em execuo.
A segunda parte uma biblioteca de rotinas de interface, na qual se encontra um

conjunto completo de primitivas, necessrias para a interao entre as tarefas de
uma aplicao. As rotinas responsveis pela comunicao entre os computadores
interligados, gerncia de processos, coordenao das tarefas, alm da verificao
e manuteno de estado da mquina virtual, esto contidas nessa biblioteca.
Os programas paralelos que utilizam o PVM fazem uso das rotinas disponibili-
zadas na biblioteca de interface do PVM. Para programao, essas bibliotecas so
distribudas em linguagens como Java, Python, Perl, alm das linguagens tradi-
cionais como C, C++ e Fortran.
Ao utilizar uma aplicao PVM, o usurio executa o pvmd3 em um dos com-

putadores do cluster, normalmente o n mestre, que chama os demais processos
pvmd3 escravos em cada computador que vai compor a mquina virtual, atravs
de remote shell - rsh, coordenando assim as comunicaes entre os processadores
e o sistema. Logo, em cada n, necessrio ter o pvmd3 instalado, sendo que
existem verses disponveis para vrios sistemas operacionais. No caso de trans-
misso entre arquiteturas diferentes, automaticamente feita uma converso dos
dados pelo formato XDR (External Data Representation), conforme RFC 1832.
11.1.2 Message Passing Interface - MPI
Segundo Gropp et al. [205], Foster [179] e Pacheco [297], o MPI um padro
de interface para a troca de mensagens em mquinas paralelas com memria
distribuda e no se devendo confundi-lo com um compilador ou um produto
especfico.

G UIA DE C LUSTER 11.1.2 - Message Passing Interface - MPI
Histrico do MPI .
O MPI o resultado do esforo de aproximadamente 60 pessoas, pertencen-

tes a 40 instituies, principalmente dos Estados Unidos e Europa. A maioria
dos fabricantes de computadores paralelos participou, de alguma forma, da ela-
borao do MPI, juntamente com pesquisadores de universidades, laboratrios
e autoridades governamentais. O incio do processo de padronizao aconte-
ceu no seminrio sobre Padronizao para Troca de Mensagens em ambiente
de memria distribuda, realizado pelo Center for Research on Parallel Com-
puting, em abril de 1992. Nesse seminrio, as ferramentas bsicas para uma
padronizao de troca de mensagens foram discutidas e foi estabelecido um
grupo de trabalho para dar continuidade padronizao. O desenho prelimi-
nar, foi realizado por Dongarra, Hempel, Hey e Walker, em novembro 1992,
sendo a verso revisada finalizada em fevereiro de 1993 (pode ser obtido em
ftp://netlib2.cs.utk.edu/mpi/mpi1.ps).
Em novembro de 1992 foi decidido colocar o processo de padronizao numa

base mais formal, adotando-se o procedimento e a organizao do HPF (the High
Performance Fortran Forum). O projeto do MPI padro foi apresentado na confe-
rncia Supercomputing 93, realizada em novembro de 1993, do qual se originou
a verso oficial do MPI (5 de maio de 1994).
Ao final do encontro do MPI-1 (1994) foi decidido que se deveria esperar mais
experincias prticas com o MPI. A sesso do Frum-MPIF de Supercomputing
94 possibilitou a criao do MPI-2, que teve inicio em abril de 1995. No Super-
Computing96 foi apresentada a verso preliminar do MPI-2. Em abril de 1997
o documento MPI-2 foi unanimamente votado e aceito. Este documento est
disponvel via HTML em http://www.mpi-forum.org/docs/mpi-20-html/
mpi2-report.html
O Padro MPI .
No padro MPI, uma aplicao constituda por um ou mais processos que se

comunicam, acionando-se funes para o envio e recebimento de mensagens en-
tre os processos. Inicialmente, na maioria das implementaes, um conjunto fixo

G UIA DE C LUSTER 11.2 - R ELAES E NTRE O Hardware E O Software PARA E XPLORAO DO PARALELISMO
de processos criado. Porm, esses processos podem executar diferentes pro-

gramas. Por isso, o padro MPI algumas vezes referido como MPMD (multiple
program multiple data).
Elementos importantes em implementaes paralelas so a comunicao de da-

dos entre processos paralelos e o balanceamento da carga. Dado o fato do nmero
de processos no MPI ser normalmente fixo, neste texto enfocado o mecanismo
usado para comunicao de dados entre processos. Os processos podem usar
mecanismos de comunicao ponto a ponto (operaes para enviar mensagens
de um determinado processo a outro). Um grupo de processos pode invocar ope-
raes coletivas (collective) de comunicao para executar operaes globais. O
MPI capaz de suportar comunicao assncrona e programao modular, atra-
vs de mecanismos de comunicadores (communicator) que permitem ao usurio
MPI definir mdulos que encapsulem estruturas de comunicao interna.
Os algoritmos que criam um processo para cada processador podem ser imple-
mentados, diretamente, utilizando-se comunicao ponto a ponto ou coletivas.
Os algoritmos que implementam a criao de tarefas dinmicas ou que garantem
a execuo concorrente de muitas tarefas, num nico processador, precisam de
um refinamento nas implementaes com o MPI.
11.2 Relaes Entre o Hardware e o Software para Ex-

plorao do Paralelismo
Esta sesso tem por objetivos caracterizar os pontos de interdependncia entre o

software e o hardware para paralelismo, e analisar as caractersticas de um modelo
ideal de programao, buscando delimitar as condies necessrias para que se
potencialize o desenvolvimento de programas destinados s arquiteturas parale-
las.

G UIA DE C LUSTER 11.2.1 - R ELAO ENTRE A LGORITMOS E A RQUITETURAS PARALELAS
11.2.1 Relao entre Algoritmos e Arquiteturas Paralelas
O foco central desta seo discutir a relao entre as caractersticas de um al-

goritmo paralelo e aquelas da arquitetura sobre a qual este ir ser processado.
Uma clareza deste inter-relacionamento fundamental para a qualidade, tanto
do projeto do hardware paralelo, como dos respectivos softwares a nvel de sistema
e aplicativo. Este tema vem despertando o interesse dos tericos j h algum
tempo. Um primeiro estudo publicado foi o de UNG [369]. A relao dos critrios
para inter-relacionamento que ser utilizada foi extrada de MOLDOVAN [277].
O tema tratado nesta seo amplo e factvel de uma abordagem terico-formal.
Foi escolhido um tratamento de modo resumido, procurando mostrar da maneira
mais genrica possvel a relao entre o hardware e o software paralelo (vide tabela
11.1). Para potencializar esta escolha, foram extrados dos textos CULLER [128],
HWANG [222] e MORSE [280] exemplos para quantificar a natureza das relaes.
Critrios para Caracterizao de Algoritmos
O critrios que sero utilizados para caracterizar o perfil do algoritmo paralelo

so: granulosidade do mdulo, controle da concorrncia, mecanismo de dados,
geometria das comunicaes e tamanho do algoritmo.
Granulosidade do mdulo: os mdulos podem ser programas, processos, rotinas

ou instrues, dependendo do nvel no qual o paralelismo est sendo explorado.
A granulosidade do mdulo indica o volume de computao que o mesmo con-
tm. relativamente usual existir abundncia de paralelismo com baixa granulo-
sidade, o qual, via de regra, no pode ser explorado com eficincia. Isto porque o
trabalho com baixa granulosidade aumenta o volume de comunicao de dados
entre os mdulos. O desempenho da arquitetura paralela obtido atravs de um
equilbrio entre granulosidade e comunicao. As comunicaes, alm do custo
de tempo que lhes inerente (o qual dependente da rede de interconexo dos
processadores), normalmente estabelecem sincronizaes entre processos.
Controle da concorrncia: diz respeito estratgia de selecionar mdulos para

execuo. A estratgia de controle deve considerar as dependncias de dados e
controle para que a execuo do algoritmo seja correta. Algumas estratgias de
controle so executadas com base na disponibilidade dos dados (dataflow), con-

Algoritmo Paralelo Arquitetura Paralela

Granulosidade do mdulo Complexidade do processador
Controle da concorrncia Modo de operao
Mecanismo de dados Estrutura da memria
Geometria das comunicaes Rede de interconexo
Tamanho do algoritmo Nmero de processadores e
tamanho da memria
Tabela 11.1: Relao entre as caractersticas do hardware e do software paralelo
trole centralizado (synchronized), ou sob demanda (demand-driven). Algoritmos

com um alto grau de regularidade, por exemplo, multiplicao de matrizes, so
indicados para um controle centralizado e so otimamente mapeados em proces-
sadores sistlicos ou outros processadores matriciais (SIMD). Por sua vez, algo-
ritmos que incorporam transferncias condicionais ou outras irregularidades no
fluxo de execuo, so melhor indicados para arquiteturas assncronas tais como
os multiprocessadores.
Mecanismo de dados: refere-se maneira como os operandos das instrues so

manipulados. Os dados gerados por uma instruo podem tanto ser utilizados
como dados puros", padro do modelo de controle por disponibilidade de da-
dos (dataflow), ou podem ser colocados em um lugar de armazenamento, e ento
referenciados pelo seu endereo, como no modelo de Von Neumann e suas exten-
ses.
Geometria das comunicaes: trata do padro como ocorrem as interconexes

entre os mdulos em execuo. A geometria das comunicaes de um algoritmo
dita regular quando o padro das interconexes repete ao longo dos ciclos da
computao, e irregular quando as interconexes so aleatrias. comum geo-
metrias regulares assumirem formas semelhantes a rvores, malhas e cubos.
Tamanho do algoritmo: indica o nmero total de computaes que o algoritmo

deve executar. Por exemplo, a manipulao de matrizes 1000 x 1000 conside-
rado um problema grande. O tamanho do algoritmo diz respeito ao nmero de
processadores e disponibilidade de memria da arquitetura paralela.

Critrios para Caracterizao das Arquiteturas Paralelas
Segundo a proposta de MOLDOVAN [277], as arquiteturas dos computadores

paralelos podem ser caracterizadas pelos seguintes critrios: complexidade do
processador, modo de operao, estrutura da memria, rede de interconexo e
nmero de processadores/tamanho da memria.
Complexidade do processador: trata do poder computacional e da estrutura in-

terna de cada elemento de processamento. Sistemas cujos processadores tem ca-
pacidade idntica so ditos homogneos. Aqueles sistemas cujos processadores
so diferentes, ou so direcionados para realizar funes especficas, so ditos
heterogneos. A complexidade do processador varia bastante de uma classe de
arquitetura para outra. Em processadores sistlicos, por exemplo, as clulas de
processamento so simples, e os dados so apenas processados, nunca armaze-
nados. Em processadores matriciais (SIMD), alguma memria precisa estar asso-
ciada ao elemento de processamento.
Em multiprocessadores, por sua vez, cada nodo de processamento pode incor-

porar memria local, memria cache, e gerenciamento de memria. A complexi-
dade do processador est associada granulosidade do algoritmo. Arquiteturas
de gro-elevado tem poucos processadores bastante poderosos; um exemplo t-
pico a conhecida arquitetura do Cray X-MP, a qual atinge no mximo quatro
processadores, porm extremamente poderosos. Um exemplo de arquitetura de
gro-mdio o multiprocessador Cedar que emprega oito clusters do Alliant FX-
8, cada cluster com oito processadores. Uma arquitetura de gro-fino utiliza um
grande nmero de processadores pequenos. Uma representante tpica desta ar-
quitetura a Conection Machine que atinge 64.536 pequenos processadores.
Modo de operao: refere-se tanto ao controle de instrues como manipulao

dos dados. O modo tradicional de operao comando-por-fluxo (command-flow),
assim chamado porque a seqncia de eventos controlada por comandos deri-
vados do fluxo de instrues. Outro mtodo disparar as operaes medida
que os seus operandos tornam-se disponveis, de acordo com o modelo comando-
por-dados (dataflow); neste caso, o controle determinado pela disponibilidade
dos dados. Outra alternativa de controle ainda, o comando-por-demanda (de-
mand-flow), no qual as computaes ocorrem somente se seus resultados so soli-
citados por outras. possvel a combinao destes modos de controle. O modo

de operao da arquitetura relacionado com o modo de controle da concorrn-

cia do algoritmo.
Estrutura da memria: refere-se ao modo de operao e organizao da mem-

ria do hardware paralelo. A memria pode ser acessada utilizando tanto endere-
os como contedo de dados (como nas memrias associativas). Em arquiteturas
no convencionais, como as orientadas a conexo (Connection Machine) ou redes
neurais, a memria consiste de interconexes ponderadas, cujo peso relativo in-
dica a alternativa a ser utilizada. Nas arquiteturas convencionais, a organizao
e o tamanho da memria esto fortemente associadas ao mecanismo de dados
utilizado pelo algoritmo.
Rede de interconexo: diz respeito s conexes de hardware entre processadores,

bem como destes com os bancos de memria. Considerando o desempenho, a
rede de interconexo deve ser o mais semelhante possvel geometria das comu-
nicaes do algoritmo paralelo. Computadores paralelos com redes de intercone-
xo simples e/ou fixas conseguem ser eficientes para um determinado conjunto
de tipos de algoritmos. Redes de interconexo complexas, ao contrrio, podem
ser configuradas para atender um ampla faixa de aplicaes; naturalmente isto
torna o hardware mais caro, e tambm possivelmente ir crescer o custo (overhead)
decorrente de um nmero maior de comutaes no caso de uma rede reconfigu-
rvel dinamicamente.
Nmero de processadores e tamanho da memria: indica quantos processadores

o sistema paralelo contm, e o tamanho da memria disponvel. Para a tecnolo-
gia atual, e considerando apenas o nmero de processadores e no o seu poder
computacional, sistemas com 1 a 100 processadores so considerados pequenos,
sistemas com 100 a 1000 processadores so considerados mdios, e sistemas com
mais de 1000 processadores so considerados grandes ou muito grandes. Como
regra geral, um nmero maior de processadores confere arquitetura um maior
poder computacional, o que faculta ao sistema paralelo trabalhar com problemas
mais complexos.
Quando o tamanho do algoritmo maior que o tamanho do sistema, se faz ne-

cessrio particionar o mesmo durante a execuo; isto implica que medida que
os mdulos de processamento (vide granulosidade do mdulo) so atribudos
aos processadores e s memrias, os resultados intermedirios precisam ser ar-
mazenados. O particionamento de algoritmos pode introduzir efeitos colaterais

G UIA DE C LUSTER 11.2.2 - P ROPRIEDADES DE UM M ODELO DE P ROGRAMAO PARA O P ROCESSAMENTO PARALELO
Figura 11.1: Modelo Para Computao Paralela
(side-effects) indesejveis. Do ponto de vista ideal, o nmero de processadores

deve ser compatvel com o tamanho do algoritmo.
A abordagem desta seo enfatizou que o processamento com desempenho oti-

mizado em arquiteturas paralelas, exige uma sintonia entre as caractersticas do
hardware e do software. A prxima seo deste captulo, objetiva apresentar as
propriedades necessrias em um modelo de programao paralela, para que o
esforo do programador para obter esta sintonia seja minimizado.
11.2.2 Propriedades de um Modelo de Programao para o Pro-

cessamento Paralelo
Uma alternativa para a situao de falta de portabilidade e curto tempo de vida

til do software paralelo o desenvolvimento de um modelo que seja abstrato o
suficiente para ocultar os aspectos da arquitetura medida que eles se alteram,
ao mesmo tempo que mantm o desempenho da aplicao paralela desenvolvida.
Em essncia, um modelo deste tipo contempla uma mquina abstrata, para a qual
o software seria desenvolvido, e que seria eficientemente emulada nas diferentes
arquiteturas paralelas. Assim, este modelo atuaria como uma fronteira entre as
arquiteturas paralelas sempre em evoluo, e o desenvolvimento de software com
sua exigncia de vida longa, desassociando os aspectos do projeto do software,
daqueles de sua implementao. A figura 11.1 resume esta proposta.
Nesta seo sero discutidos os aspectos de um modelo ideal para o desenvolvi-

mento de software paralelo. A organizao adotada foi proposta em SKILLICORN
[333]. Os recursos mnimos que este modelo deve oferecer so os seguintes:

Facilidade para o Desenvolvimento do Software
Os aspectos pertinentes ao controle da execuo paralela so bastante comple-

xos. Na medida do possvel, o modelo deve retirar do programador a respon-
sabilidade sobre os mesmos. Para tanto, deve ficar ao encargo do compilador e
do ambiente de execuo, a insero e a gerncia dos mecanismos necessrios.
Assim, o modelo deve prover:
decomposio do programa em tarefas paralelizveis. Para sua execuo

paralela, o programa deve ser dividido em partes passveis de serem execu-
tadas concorrentemente pelos diversos processadores da arquitetura. Isto
implica em fracionar o cdigo e a estrutura de dados em partes, cujo n-
mero e tamanho so funo das caractersticas da arquitetura;
mapeamento das tarefas paralelas aos processadores. Uma vez que o pro-
grama tenha sido dividido, se faz necessria a deciso de em qual proces-
sador ser alocada cada tarefa. Um dos principais critrios para deciso
o volume de comunicaes, de tal forma que tarefas com volume de comu-
nicaes elevado entre si tenham posies o mais prximo possvel na rede
de interconexes. No caso de arquiteturas heterogneas (vide item 11.2.1),
pode ser muito significativo para o desempenho levar em conta as caracte-
rsticas do processador no momento da alocao de uma determinada ta-
refa;
comunicao entre as tarefas paralelas. Sempre que uma tarefa necessita

de um dado no disponvel localmente, algum mecanismo de comunicao
deve ser ativado para obt-lo. A forma especfica de atuao do mecanismo
dependente da arquitetura, porm indispensvel que as tarefas parale-
las que trocam dados tenham suporte para tal, evitando atrasos no proces-
samento em funo de dados que custam a vir, ou que eventualmente nem
mesmo viro;
sincronizao entre as tarefas paralelas. relativamente usual no processa-

mento paralelo, duas ou mais tarefas precisarem confirmar se todo o grupo
j atingiu determinado ponto comum da computao. Neste caso, tambm
a especificidade do mecanismo que ser utilizado fortemente dependente
da arquitetura. O tema sincronizao bastante amplo e complexo. Existe

na relao entre comunicao e sincronizao um grande potencial para in-

consistncias no estado de execuo (deadlocks).
Uma Metodologia para o Desenvolvimento de Software
O recurso previsto no item anterior (11.2.2), deixa clara a distncia semntica en-
tre a informao a ser disponibilizada pelo programador e a necessria para exe-
cuo do programa em paralelo. Para superar isto, se faz necessria uma slida
fundamentao semntica, sobre a qual as tcnicas de transformao de cdigo
possam ser aplicadas.
A usual metodologia de testes e depurao utilizada na programao seqencial,

se mostra invivel para o desenvolvimento de software paralelo, sobretudo pelos
seguintes motivos:
o particionamento e o mapeamento das tarefas, os quais podem em alguns

casos depender dos dados, ampliam a um ponto tal a complexidade da an-
lise dos possveis estados da computao paralela que seu uso efetivo pra-
ticamente invivel;
a equipe de desenvolvimento teria acesso apenas a algumas das arquitetu-

ras paralelas nas quais o software poderia vir a ser executado. Este aspecto
fica reforado pela heterogeneidade que as arquiteturas paralelas podem
assumir, bem como pelo constante surgimento de arquiteturas com novas
tecnologias no mercado.
a existncia, nas arquiteturas paralelas, de componentes que dificultam a

reproduo exata de execues, como por exemplo o no determinismo ine-
rente maioria das redes de interconexo.
Como a comprovao do comportamento dos possveis estados do software pa-

ralelo aps seu desenvolvimento, se mostra complexo demais para uso prtico,
somente um processo, que leve na direo de um software correto por metodo-
logia de construo, colocar o desenvolvimento de software em um patamar de
segurana e conforto razoveis (vide item 5.1.8).

Independncia de Arquitetura
O modelo deve ser independente de arquitetura, de tal forma que os programas

possam migrar entre as arquiteturas paralelas, sem exigir alteraes no cdigo ou
outras modificaes no triviais. Por outro lado, as arquiteturas paralelas, como
aglutinam diversas tecnologias, todas em constante evoluo, tem sua vida til
efetiva de poucos anos. Isto torna pouco razovel considerar a rescrita do software
a cada necessidade de trocar o hardware.
Atender este aspecto de independncia de arquitetura de forma individual uma

tarefa factvel. Existem diversos modelos cujo nvel de abstrao satisfazem este
aspecto (vide item 11.3.1).
O complexo atender este requisito em conjunto com os outros, que um bom

modelo para o desenvolvimento de aplicaes paralelas deve suprir.
Facilidade para Ser Entendido
Um modelo, para que se dissemine largamente, deve ser fcil de ser entendido. Se
o processamento paralelo pretende ampliar sua fatia de mercado, o modelo para
sua programao deve poder ser assimilado com facilidade pelos desenvolvedo-
res, oferecendo para isto uma interface que oculte ao mximo a complexidade
inerente ao paralelismo e seja de uso simples.
Garantia de Desempenho
Um modelo deve garantir o desempenho dos programas para ele desenvolvidos,

nos diversos tipos de arquiteturas disponveis. Segundo SKILLICORN [333], so-
mente um modelo com otimizao nas comunicaes pode ter previsibilidade
no desempenho. Por sua vez, considerando a diversidade dos problemas reais,
heursticas complexas para otimizar o mapeamento das tarefas paralelas, consi-
derando o custo das comunicaes, podem introduzir custo computacional ele-
vado. Assim, somente modelos que limitem a freqncia das comunicaes, po-
dem esperar ter uma garantia mnima de desempenho em diferentes hardwares

paralelos.
Medidas de Custo
O desenvolvimento de software para arquiteturas paralelas tem sempre presente

a premissa de buscar o maior desempenho possvel, o que tem reflexos diretos no
tempo que o programa exige do hardware para completar sua execuo.
Alm do desempenho global, a taxa de utilizao individual dos processadores,

e o custo de desenvolvimento, so importantes indicadores para anlise do custo
total decorrente das etapas de projeto, programao e execuo do software para-
lelo.
A proporcionalidade de desempenho entre as plataformas seqenciais, faculta

que uma anlise da complexidade dos algoritmos empregados no programa traga
uma expectativa de desempenho, independentemente do hardware especfico que
ser utilizado. Na programao paralela tal situao no ocorre; pequenas mo-
dificaes no programa ou a troca do hardware paralelo podem mudar completa-
mente o comportamento do programa (vide item 11.2.1 ).
Segundo SKILLICORN [333] um modelo oferece medidas de custo se for possvel

determinar o custo de um programa, em particular a partir de:
cdigo fonte do programa;
propriedades mnimas da arquitetura paralela destino (por exemplo, o n-

mero de processadores);
informaes a respeito do tamanho dos dados de entrada (no os seus va-

lores);
No texto SKILLICORN [333], tambm caracterizada a importncia de conside-

rar os aspectos de modularidade. relativamente usual que o software de grande
porte seja desenvolvido por mdulos, e possivelmente cada mdulo por equipes
diferentes. Isto implica que a medida de custo precisa ter um comportamento
composicional, isto , o custo total possa ser inferido a partir do custo das partes.

G UIA DE C LUSTER 11.3 - A E XPLORAO DO PARALELISMO : N VEIS DE A BSTRAO E M ODELOS
Considerando as outras caractersticas indispensveis para um modelo de pro-

gramao paralela, por exemplo, a necessidade de abstrao tratada no item
11.2.2 a medida de custo se torna uma caracterstica difcil de ser atingida.
11.3 A Explorao do Paralelismo: Nveis de Abstra-

o e Modelos
O objetivo deste captulo caracterizar a potencialidade para explorao do pa-

ralelismo em diferentes modelos de programao.
A classificao utilizada tem como critrio o nvel de abstrao com que a explo-
rao pode ser feita. Estes nveis de abstrao esto sugeridos em SKILLICORN
[333] e BAL [74]. A partir de textos especficos sobre os modelos, foram feitas
consideraes, e selecionados exemplos de sistemas paralelos.
11.3.1 Modelos nos quais o Paralelismo Explorado de Forma

Totalmente Implcita
Nestes modelos, o programador descreve somente o propsito da computao, o

que o programa deve fazer, e no como deve ocorrer o processamento para que o
programa atinja seu propsito.
O desenvolvimento de software no precisa levar em considerao se o programa

ir executar em paralelo ou no. Em funo disto, estes modelos trabalham em
um nvel de abstrao elevado, e os programas desenvolvidos pensando no pa-
ralelismo no so necessariamente mais complexos que os elaborados para exe-
cuo seqencial.
Como exemplos caractersticos deste nvel de abstrao na explorao do parale-

lismo, destacam-se a programao funcional e a programao em lgica.

G UIA DE C LUSTER 11.3.1 - M ODELOS NOS QUAIS O PARALELISMO E XPLORADO DE F ORMA T OTALMENTE I MPLCITA
Figura 11.2: Nmeros de Fibonacci em Programao Funcional
Programao Funcional
A programao funcional uma alternativa elegante de programao declara-

tiva, na qual o programa definido por um conjunto de equaes e funes, cujo
resultado da computao a soluo das mesmas.
Os dois aspectos que tornam este paradigma atrativo tanto o nvel de abstrao
em que pode ser feito o desenvolvimento de software, como o fato do mesmo ser
suscetvel de uma avaliao formal.
A entidade central da programao funcional a funo. Deste modo, funes

podem devolver como resultados outras funes, as quais podem ser passadas
como argumentos. A semntica de um programa funcional puro garante a au-
sncia de efeitos colaterais (side-effects) entre as sub-expresses de uma funo;
isto faculta uma anlise paralela das mesmas, sem riscos de dependncias de da-
dos e/ou controle, JONES [238].
Um clssico programa que ilustra a possibilidade de avaliao paralela de sub-

expresses o algoritmo recursivo de Fibonacci:
Como as duas chamadas recursivas de fibonacci so independentes, podem ser

executadas em paralelo.
Fonte Implcita de Paralelismo
A tcnica utilizada para linguagens funcionais puras (de alta ordem e sem ano-
taes) denominada reduo de grafo (Graph Reduction), PEYTON-JONE [300].
As funes so expressas como rvores, com sub-rvores comuns (para represen-
tar as sub-funes compartilhadas). A computao consiste em selecionar subes-
truturas do grafo, reduz-las a formas mais simples e atualizar o grafo com as
mesmas. Quando no existirem redues a serem feitas, o grafo que resta o
resultado da computao.

Utilizando regras de excluso para evitar sobreposies, mltiplos processadores

podem pesquisar simultaneamente diferentes regies do grafo correspondente
ao programa. As redues das sub-rvores poderiam, ento, ser realizadas em
paralelo.
Potencialidade de Explorao do Paralelismo
Uma vez que o grafo correspondente ao programa funcional sem nenhum tipo
de anotao varia de forma muito dinmica durante sua reduo, bastante dif-
cil gerenciar a distribuio de carga entre processadores, o total de novas tarefas
criadas e o volume de comunicaes. Segundo HANUS [210], a explorao total-
mente implcita do paralelismo na programao funcional resulta em um grande
nmero de tarefas paralelas de pequena granulosidade.
Os modelos atualmente existentes para explorao totalmente implcita do para-

lelismo com programao funcional, tem obtido desempenho razovel em equi-
pamentos com memria compartilhada, no conseguindo boa eficincia com
equipamentos de memria distribuda (HUDAK [219]).
Programao em Lgica
Uma importante caracterstica das linguagens de programao em lgica que as

mesmas so de atribuio nica. Assim, de forma diferente das linguagens im-
perativas, elas no permitem atribuies destrutivas s variveis, nem controle
explcito do fluxo de execuo do programa. Isto confere s linguagens de pro-
gramao em lgica, uma semntica clara (declarativa) e uma decorrente cons-
truo de programas elegantes, compactos e menos sujeitos a erros oriundos de
aspectos de implementao (STERLING [346]).
Este forte aspecto declarativo permite que a avaliao de um programa em lgica

possa ser feita por diferentes estratgias de controle de fluxo de execuo. Isto
implica que a ausncia de efeitos colaterais decorrentes da semntica declarativa
faculta que muitas das operaes em um programa em lgica possam ser execu-
tadas em qualquer ordem (no determinismo), sem que com isto seja afetada a
consistncia de execuo do mesmo.

Fontes Implcitas de Paralelismo
Existem duas principais fontes de paralelismo implcito na programao em l-

gica (KERGOMMEAUX [244]):
Paralelismo OU: este tipo de paralelismo refere-se a uma estratgia de busca pa-
ralela na rvore de metas do programa lgico. Assim, quando o processo de
busca encontra uma ramificao na rvore de metas, ele pode iniciar processos
paralelos de busca em cada ramo descendente (vide figura 11.3). O nome parale-
lismo OU deriva do fato que, em programas lgicos no determinsticos, existem
vrias respostas (vrios caminhos) que satisfazem o objetivo.
Paralelismo E: em termos da rvore de metas (vide figura 11.3), o paralelismo

E corresponde construo paralela de uma ramificao. Neste caso, quando o
processo de busca reconhece que um nmero de passos deve ser efetuado para
completar um ramo, ele pode iniciar processos paralelos para avaliar estes passos.
Outra fonte de paralelismo implcito na programao em lgica o paralelismo

de unificao. O paralelismo disponibilizado de baixa granulosidade e, para ser
explorado com eficincia, exige hardware especializado.
O paralelismo E, por sua vez, pode ser explorado entre literais independentes
(sem possibilidade de conflito na atribuio de valores a variveis), ou entre
quaisquer literais, s custas de um mecanismo mais complexo de deteco e ge-
rncia do paralelismo.
Exemplo de Explorao do Paralelismo
A grande maioria dos modelos que exploram paralelismo na programao em

lgica, implementam a linguagem Prolog (STERLING [346]), e utilizam a WAM
(Warren Abstract Machine - WARREN [380], AIT-KACI [49]) como estratgia de
compilao.
O OPERA (BRIAT [96], GEYER [195]) um exemplo de modelo que explora de

forma implcita o paralelismo OU. Neste modelo, o paralelismo explorado de
forma multiseqencial, no qual cada processador ativo est, em determinado mo-
mento, trabalhando de forma independente, sobre um ramo especfico da rvore
de busca.

Figura 11.3: Fontes de Paralelismo na Programao em Lgica
O modelo &-Prolog (HERMENEGILDO [213]) um dos mais maduros modelos

explorando paralelismo E independente. Ele combina uma deteco de inde-
pendncia a nvel de compilao com um eficiente ambiente de execuo imple-
mentado em multiprocessadores com memria compartilhada. Sua proposta
fundamentada no Paralelismo E Restrito (DEGROOT [148]).
O paralelismo pode ser explorado automaticamente, a partir de um programa em

Prolog padro (opcionalmente o programador pode fazer anotaes). O compi-
lador do modelo executa a transformao de programas Prolog para &-Prolog. A
anlise esttica do compilador detecta a independncia entre literais, mesmo na
presena de predicados com side-effects (MUTHUKUMAR [281] e [282]).
Os programas &-Prolog so compilados em uma extenso da WAM denominada

PWAM, cuja principal diferena em relao a WAM a adio de uma pilha de
literais paralelizveis, onde processadores inativos retiram trabalho.
As alternativas de explorao do paralelismo na programao em lgica so for-

temente ortogonais entre si; isto significa que podem ser explorados simultanea-
mente, sem que um comprometa o outro.
O paralelismo OU, presente em programas com no determinismo, caracteriza-se

G UIA DE C LUSTER 11.3.2 - M ODELOS COM A SSINALAMENTO DO PARALELISMO E XPLCITO
por uma granulosidade mais elevada, o que faculta sua explorao em mquinas
de memria distribuda. Por sua vez, o paralelismo E, passvel de ser explorado
praticamente em qualquer programa em lgica, apresenta uma granulosidade
pequena, da a maioria dos modelos existentes serem orientados a equipamen-
tos de memria compartilhada (baixo custo de comunicao) (KERGOMMEAUX
[244]).
Os modelos para explorao do paralelismo na programao em lgica de forma

totalmente implcita, apresentam um elevado nvel de abstrao. Este aspecto,
que lhes confere elegncia, portabilidade e possibilidade de aproveitamento de
toda cultura da programao seqencial disponvel, tambm dificulta a garantia
de desempenho destes modelos frente diversidade das aplicaes reais. Porm,
importante ter presente que situaes de bom ganho de desempenho foram
registradas. Por sua vez a elevada dinmica da programao em lgica dificulta
sobremaneira qualquer medida de custo.
A explorao do paralelismo na programao em lgica se mostra promissora. A

maioria dos modelos implementados explora somente um tipo de paralelismo,
uns poucos exploram dois tipos, e nenhum explora efetivamente todas as alter-
nativas de paralelismo possveis.
O custo-benefcio da explorao implcita do paralelismo ainda no atingiu pata-

mares satisfatrios (KERGOMMEAUX [244]).
11.3.2 Modelos com Assinalamento do Paralelismo Explcito
Nestes modelos, o programador deve estar ciente da natureza do paralelismo

que ser explorado, e deve expressar todo o potencial para o mesmo no cdigo,
porm no precisa se envolver como este ser efetivamente tratado pelo ambiente
de execuo. Portanto, fica a cargo do modelo como ir ocorrer a decomposio,
o mapeamento, a comunicao e a sincronizao das tarefas paralelas.
Assim, o programa deve expressar o mximo paralelismo inerente ao algoritmo.

A implementao do mesmo (compilao e execuo), por sua vez, reduzir este
nvel de paralelismo ao possvel de ser explorado em funo da arquitetura des-
tino e dos decorrentes custos de escalonamento, comunicao e sincronizao.

Como exemplo de paralelismo neste nvel de abstrao temos explorao do pa-

ralelismo de dados.
Paralelismo de dados - explorao de laos
O paralelismo de dados tem uma origem histrica no uso de processadores pipe-

line. Neste caso, a explorao de paralelismo ocorria com a aplicao de forma
independente e repetida de uma mesma operao sobre dados diferentes. Tal si-
tuao permitia o uso de processadores com registradores vetoriais, com os quais
o paralelismo era explorado, associado a um custo reduzido de controle das re-
peties.
Com o desenvolvimento das arquiteturas matriciais (SIMD), as mesmas se torna-

ram timas candidatas para processar em paralelo o cdigo vetorizado. Por sua
vez, o cdigo para arquiteturas matriciais pode ser eficientemente executado em
multiprocessadores.
Deste modo, o paralelismo de dados, inicialmente destinado a pipelines vetoriais,

pode atualmente ser explorado em diversas arquiteturas paralelas.
Assim, genericamente, o paralelismo de dados uma estratgia na qual as rotinas

paralelas so composies de operaes aplicadas a dados de um determinado
tipo, e que produzem resultados do mesmo tipo.
Fonte de paralelismo
No caso mais usual, o paralelismo de dados envolve estruturas de dados orga-

nizadas na forma de matrizes de dimenses variadas (estruturas regulares), e o
paralelismo se viabiliza quando estes dados so passveis de manipulao inde-
pendente. Esta manipulao independente comum na lgebra matricial.
Como exemplos tpicos de modelos que exploram paralelismo de dados surgem

os diversos dialetos FORTRAN. O HPF (High Performance Fortran - THAKUR
[359], MEHROTRA [273]), particularmente, potencializa a explorao do parale-

lismo de dados inerente aos laos, disponibilizando construtores que devem ser
utilizados nos programas para determinar como as estruturas de dados devem
ser alocadas aos processadores.
Para fazer isto o programador precisa ter clareza da relao entre os dados.
O cdigo para explorao do paralelismo de dados simples de ser escrito e

depurado. Isto decorre do paralelismo ser explicitamente trabalhado pelos sin-
cronismo e fluxo de controle inerentes aos equipamentos matriciais.
Os programas para paralelismo de dados necessitam, para sua execuo, de uma

pr-distribuio dos conjuntos de dados que sero manipulados. Deste modo, a
organizao das estruturas de dados utilizadas neste tipo de paralelismo deter-
minante para o seu desempenho.
Portanto, este paralelismo centrado em computaes locais e operaes de ma-

nipulao de dados (replicaes, permutaes, redues, etc.). Pode ser explo-
rado com sucesso mesmo em problemas de baixa granulosidade, desde que estes
utilizem conjuntos de dados com estruturas multidimensionais regulares.
Dependendo da granulosidade inerente ao problema e do algoritmo adotado, o

paralelismo de dados pode tambm ser explorado em multiprocessadores tanto
de memria compartilhada como distribuda.
Porm, seu emprego mais facilmente potencializado nas arquiteturas sncronas,

as quais conseguem explorar eficientemente o paralelismo a nvel de instruo.
O paralelismo de dados, tem sido utilizado com timos desempenhos em diver-

sas arquiteturas. A simplicidade do seu cdigo facilita a codificao e eventuais
recodificaes quando de migraes entre arquiteturas diferentes. Faculta uma
previso de desempenho e tambm medida de custo. Porm, possvel sua ex-
plorao com desempenho somente quando os dados tiverem as caractersticas
de independncia e regularidade mencionadas.

G UIA DE C LUSTER 11.3.3 - M ODELOS COM A SSINALAMENTO E D ECOMPOSIO DO PARALELISMO E XPLCITOS
11.3.3 Modelos com Assinalamento e Decomposio do Parale-

lismo Explcitos
Estes modelos delegam para o programador a deciso de como ser decomposto

o trabalho paralelo. As implicaes desta deciso, no entanto, sero tratadas de
forma transparente pelo modelo.
Uma vez divido o problema, a atribuio das partes aos processadores e a forma
como estas vo se comunicar e sincronizar no precisam ser explicitadas no pro-
grama.
Existem poucas propostas neste nvel de abstrao (somente duas), e sua imple-
mentao ocorre na forma de bibliotecas utilizadas a partir das linguagens C e
FORTRAN. Como exemplo deste nvel de abstrao, surge a explorao do para-
lelismo com restrio de comunicaes e sincronizao.
Um modelo que explora o paralelismo neste nvel o BSP (Bulk Synchronous Pa-
rallelism model - SKILLICORN [332], VALIANTE [371]). As computaes em BSP
so divididas em fases, alternando comunicaes globais e computaes locais.
Cada fase inicia com a ativao das operaes de comunicao. O processamento

nas tarefas paralelas ocorre utilizando somente referncias a dados locais. En-
quanto isto, de forma independente, a rede de interconexes realiza as trocas de
dados necessrias entre os processadores. Ao final de cada fase, chamadas de
superstep, todas as comunicaes so entendidas como prontas (para garantir isto
utilizada uma barreira de sincronizao) e todas as atribuies feitas memria
global (que dizem respeito tarefa paralela do processador) so reproduzidas lo-
calmente. Do ponto de vista do programador, as solicitaes de dados memria
global remota sero feitas pelo BSP no superstep anterior quele no qual eles sero
utilizados.
Uma caracterstica que se destaca no BSP o fato do mesmo expressar as pro-

priedades da rede de interconexo utilizada na arquitetura paralela a partir de
uns poucos parmetros. A mquina abstrata do BSP consiste de uma coleo de

G UIA DE C LUSTER 11.3.3 - M ODELOS COM A SSINALAMENTO E D ECOMPOSIO DO PARALELISMO E XPLCITOS
p processadores, cada qual com sua memria local, todos conectados atravs da
rede de interconexo. Os parmetros da rede de interconexo utilizados so: l
tempo necessrio para a realizao da barreira de sincronizao, e g - a razo na
qual dados locais com endereo aleatrio podem ser liberados/recebidos. Estes
parmetros so determinados experimentalmente para cada computador para-
lelo.
Deste modo, se o tempo consumido com computaes locais exigir um total w e

o volume de valores recebidos e enviados pelo processador for h, ento o tempo
total gasto em um superstep :
t = w + hg + l
Considerando que a computao seqencial tem diversas mtricas de comple-

xidade disponveis, e trabalhando com o maior valor previsto para as variveis
anteriores, o tempo mximo que um superstep ir depender pode ser facilmente
obtido.
O outro modelo que trabalha neste nvel de abstrao o logP (CULLER [129]).
Tambm neste modelo so utilizadas threads com contextos locais e com atualiza-
es de dados por comunicaes globais.
O nvel de abstrao dos programas em BSP bastante elevado.
Apesar de sua decomposio em threads ser feita pelo programador, a alocao

das mesmas e toda comunicao/sincronizao feita de forma transparente
para o mesmo.
Podem ser obtidos bons desempenhos com o modelo do BSP, porm sua previsi-
bilidade influenciada pelos seguintes fatores:
Comunicaes: a otimizao das comunicaes depende de como ocorre a aloca-

o (automtica) das threads aos processadores, tendo em vista as caractersticas

G UIA DE C LUSTER 11.3.4 - M ODELOS COM A SSINALAMENTO , D ECOMPOSIO E M APEAMENTO DO PARALELISMO E XPLCITOS
da rede de interconexo (topologia, largura de banda, etc.);
Sincronizao: o custo total introduzido pelas barreiras de sincronizao entre

cada fase de execuo, depende da natureza do problema e do algoritmo utili-
zado (sua granulosidade, possibilidade de ser particionado em partes homog-
neas, etc.).
Por outro lado, um ponto forte do modelo BSP a existncia de medida de custo,
atravs da qual possvel obter o custo real de execuo de um programa para
qualquer arquitetura, desde que sejam conhecidos os parmetros l e g para a
mesma.
A verso corrente do BSP trabalha com uma biblioteca SPMD (Simple Program
Multiple Data), que fornece operaes para colocar dados na memria remota de
outro processo, para receber dados de um processo remoto e para sincronizao
(pode ser utilizada a partir de C ou FORTRAN).
11.3.4 Modelos com Assinalamento, Decomposio e Mapea-

mento do Paralelismo Explcitos
Nestes modelos, o programador, alm de dividir o programa em partes, tem a in-

cumbncia de avaliar qual o melhor processador para cada parte. Uma vez que a
proximidade dos processadores determinante para o desempenho das comuni-
caes, indispensvel para o programador ter conhecimento das caractersticas
da rede de interconexes utilizada na arquitetura. Este comprometimento do c-
digo com as caractersticas do equipamento, trazem repercusses nos custos de
migrao de software entre diferentes arquiteturas.
Por sua vez, o ambiente de execuo se responsabiliza pelo gerenciamento das

comunicaes e das sincronizaes entre as tarefas paralelas.

G UIA DE C LUSTER 11.3.4 - M ODELOS COM A SSINALAMENTO , D ECOMPOSIO E M APEAMENTO DO PARALELISMO E XPLCITOS
Um modelo que trabalha neste nvel de abstrao o Linda" (CARRIERO [106]).

Neste conhecido modelo, as comunicaes ponto-a-ponto so substitudas por
um espao compartilhado, no qual os dados so colocados pelos processadores
e a partir do qual so recuperados associativamente. Este espao denominado
espao de tuplas.
As trs operaes bsicas do modelo de comunicaes utilizado pelo Linda so:

uma que l o espao de tuplas buscando aquelas que satisfazem os campos infor-
mados e a correspondente aridade, uma segunda que faz a leitura porm remove
a tupla que sastisfaz a condio do espao de tuplas e uma terceira que coloca
uma tupla no espao de tuplas.
As operaes de comunicao em Linda desconectam o emissor do receptor, isto

, a thread que envia informao, em nenhum momento precisa saber qual vai
receb-la. No existe conexo nem espacial e nem temporal entre os mesmos.
Como as comunicaes entre programas exigem que ambos os lados (emissor

e receptor) tenham seus parmetros devidamente concordantes, e considerando
que os programas paralelos usualmente contemplam muitas comunicaes, esta
tarefa de especificar comunicaes introduz um custo elevado no desenvolvi-
mento do software paralelo.
Os modelos que operam neste nvel de abstrao reduzem muito este custo, ofe-
recendo primitivas de alto nvel para especificao das trocas de dados. Nor-
malmente esta simplificao feita separando, nos programas, os aspectos de
processamento dos de comunicao. Normalmente disponibilizada uma lin-
guagem a parte (subconjunto da linguagem) para tratar das comunicaes. Esta
diviso faz com que a computao e a comunicao fiquem ortogonais entre si, de
tal forma que uma particular estratgia para as comunicaes possa ser utilizada
com diversas linguagens seqenciais. Este o caso particular de Linda.
preciso ter presente que a combinao de decomposio explcita do parale-

G UIA DE C LUSTER 11.3.5 - M ODELOS COM A SSINALAMENTO , D ECOMPOSIO , M APEAMENTO E C OMUNICAO E XPLCITOS
lismo, com um mecanismo de troca de dados que garante um desacoplamento

entre as partes comunicantes, uma fonte de possveis inconsistncias no estado
de execuo do programa paralelo (deadlocks). Por exemplo, uma thread pode ficar
bloqueada aguardando uma tupla que nunca ser inserida no espao de tuplas.
Apesar de ser possvel um desacoplamento entre emissor e receptor, o algoritmo
introduz necessidades de sincronizao (que neste caso feita atravs dos dados)
que so inerentes natureza do algoritmo que est sendo computado.
Como a eficincia da implementao das abstraes de alto nvel utilizadas na

construo e gerncia do espao de tuplas (comunicaes) dependente da rede
de interconexo utilizada na arquitetura, no possvel trabalhar com medidas
de custo.
11.3.5 Modelos com Assinalamento, Decomposio, Mapea-

mento e Comunicao Explcitos
Nestes modelos, o programador tem a seu encargo especificar quase todos os de-
talhes da implementao paralela, exceto os aspectos pertinentes a sincronizao.
Para oferecer isto, via de regra, estes modelos empregam uma semntica assn-
crona, na qual as mensagens so enviadas, porm o emissor no fica atrelado ao
tempo necessrio para que elas atinjam seu destino.
O mais importante modelo nesta classe Atores (Actors - AGHA [47]). Ele con-
siste de uma coleo de objetos chamados atores, todos contendo uma pilha de
mensagens de entrada. Todo ator executa repetidamente a seqncia: leitura da
mensagem disponvel na pilha de entrada; envia suas mensagens a todos os ou-
tros atores que ele conhece e a partir das mensagens que chegaram define seu
novo contexto, o qual determinar suas respostas s prximas mensagens que
receber.
As mensagens so enviadas de forma assncrona e sem preocupao de ordem.

G UIA DE C LUSTER 11.3.6 - M ODELOS NOS QUAIS O PARALELISMO E XPLORADO DE F ORMA T OTALMENTE E XPLCITA
Os nomes dos atores podem ser distribudos atravs de mensagens. A explorao

de concorrncia e distribuio em objetos amplamente discutida em BRIOT [97].
Alm dos custos de comunicao, outro ponto de estrangulamento (gargalo) do

desempenho do modelo de atores o processamento seqencial das mensagens
na fila de entrada. Para minimizar este aspecto, o modelo ActorSpace (AGHA
[45]) prope estratgias para reduzir o nmero de mensagens distribudas.
A comunicao entre processadores no modelo atores e seus derivados grande,

o que aumenta consideravelmente o indeterminismo introduzido pelo desempe-
nho da rede de interconexes da arquitetura. Em funo disto, no possvel
nestes modelos dar, garantia de desempenho, ou medida de custo.
11.3.6 Modelos nos quais o Paralelismo Explorado de Forma

Totalmente Explcita
Nestes modelos o programador precisa especificar todos os aspectos da imple-

mentao. Em funo disto, se torna uma tarefa trabalhosa desenvolver software
empregando tais modelos, porque tanto a sua correo quanto seu desempenho,
somente podem ser atingidos pela criteriosa ateno de um grande nmero de
detalhes.
Os primeiros modelos para o paralelismo, na sua grande maioria, atuavam neste

nvel, normalmente voltados para um particular tipo de arquitetura, e com sua
execuo paralela gerenciada de forma totalmente explcita.
Um conhecido exemplo de explorao de paralelismo neste nvel a linguagem

SR (Synchronizing Resources - ANDREWS em [63] e [64] e ANDREWS e OLSSON
em [66], [67] e [68]). Nesta linguagem, esto presentes as caractersticas usuais do

G UIA DE C LUSTER 11.3.6 - M ODELOS NOS QUAIS O PARALELISMO E XPLORADO DE F ORMA T OTALMENTE E XPLCITA
paradigma convencional (imperativo), tais como: tipos, variveis, atribuio des-

trutiva, comandos de controle de repetio, comandos de seleo simples e mlti-
pla, procedimentos, etc. Para explorao do paralelismo SR fornece mecanismos
especficos para gerenciamento da concorrncia, comunicao e sincronizao.
Em SR um programa pode ser formado por diversos espaos de endereamento

(mquinas virtuais), os quais podem estar localizados em mltiplos computado-
res (mquinas fsicas). Os processos residentes em um mesmo espao de endere-
amento podem compartilhar memria. Desta forma, a linguagem SR suporta
programao em ambientes distribudos e ambientes com memria comparti-
lhada. SR baseada no conceito de recurso (resource). O recurso um mdulo
que pode conter diversos processos.
Um recurso dinamicamente criado de maneira explicita, pelo comando create.

Os seus processos comunicam-se utilizando semforos para sincronizao. A co-
municao entre processos de recursos remotos pode ser feita atravs de troca de
mensagens assncronas, chamada remota de procedimentos (RPC) e rendezvous.
De forma anloga a outros modelos de sua categoria, a linguagem SR no oferece

recursos de abstrao para deteco, decomposio, comunicao ou sincroni-
zao do paralelismo. A SR, tambm como outros modelos anlogos, costuma
oferecer mecanismos alternativos para o programador gerenciar o paralelismo,
porm, mesmo assim, invivel conciliar em um programa independncia de
arquitetura e mximo desempenho.
Dependendo da arquitetura, problemas de qualquer granulosidade podem ser

computados com desempenho em SR. Para uma arquitetura em particular, SR
oferece garantia de desempenho e medida de custo, no entanto, pelos detalhes
que exige, torna o desenvolvimento de software paralelo uma tarefa onerosa.

Captulo 12
Escalonadores de Tarefas
Sistemas de job scheduler", ou de agendamento/escalonamento de tarefas, para

clusters e grids so softwares desenvolvidos para controlar a execuo dos
jobs" ou tarefas no ambiente. Esse tipo de software composto normalmente
por um gerenciador de filas de processamento (batch queue manager") que pri-
oriza e controla a execuo de mltiplas tarefas. Job schedulers" so tambm,
conhecidos como gerenciadores de distribuio de recursos ou gerenciadores de
filas de execuo.
As caractersticas bsicas esperadas de um job scheduler" so:
Interface para se definir o fluxo e/ou a rvore de dependncia de execuo

dos trabalhos;
Submisso automtica das tarefas para execuo;
Interfaces para monitoramentos das execues;
Controle das prioridades e das filas de tarefas, para controlar a ordem de

execuo das tarefas.
Vrios sistemas como ERPs, Bancos de dados, sistemas de cpias de segurana,

incluem ou podem usar algumas caractersticas de sistemas de agendamento de
tarefas.

G UIA DE C LUSTER 12.1 - O PEN PBS
Alguns exemplos de ferramentas utilizadas em ambientes de cluster para job

scheduler"sero descritos a frente:
openPBS 12.1;
TORQUE 12.2;
MAUI 12.3;
Crono12.4.
12.1 OpenPBS
Stio: http://www.openpbs.org/
O propsito do sistema OpenPBS prover controles adicionais sobre a inicializa-

o ou o seqenciamento de execuo de grupos de tarefas, e permitir a distri-
buio destes trabalhos entre vrios ns de um cluster. O sistema de controle de
tarefas (batch server) permite que sejam definidas e implementadas regras para
diferentes tipos de recursos e para a quantidade de recursos pode ser usada por
diferentes tarefas. Este sistema tambm prov um mecanismo com o qual um
usurio pode assegurar que uma tarefa tenha os recursos necessrios para ser
completada.
Este sistema de controle de tarefas constitudo por um conjunto de componen-

tes: um servidor, clientes e comandos de usurios. O servidor gerencia diferentes
objetos, como tarefas e filas de execuo.
Interaes tpicas entre os componentes so baseadas no modelo cliente-servidor,

um cliente faz requisio para o servidor, a execuo de uma tarefa, e o servidor
executa o trabalho em um de seus clientes. Clientes no podem criar ou modificar
os objetos diretamente, eles dependem de uma ordem do servidor que gerncia
estes objetos.
O servidor de tarefas um processo permanente (daemon) ou um conjunto de

processos . O servidor de tarefas gerencia os objetos (trabalhos a serem executa-
dos), assim como, as filas e as tarefas. Ele prov servios como: criao, execuo,

G UIA DE C LUSTER 12.2 - TORQUE
modificao, excluso e roteamento de tarefas para os clientes (ns computacio-

nais) responsveis pela execuo dessas tarefas.
12.2 TORQUE
Stio:
http://www.clusterresources.com/pages/products/
torque-resource-manager.php
TORQUE um gerenciador de recursos em cdigo aberto que prov controle so-

bre tarefas (batch jobs) em ns computacionais distribudos. Ele um esforo da
comunidade de software livre, baseado no cdigo original do projeto *PBS, e que
j conta com mais de 1.200 correes e melhorias de cdigo, com melhorias sig-
nificativas em reas como escalabilidade, tolerncia falhas e novas extenses.
Alguns contribuidores do projeto so: NCSA, OSC, USC , U.S. Dept of Energy,
Sandia, PNNL, U-Buffalo, TeraGrid e outras organizaes lderes em desenvolvi-
mento de HPCs.
Caractersticas:
Tolerncia falhas:
Suporte a checagem de ns fora do ar;
Vrias condies de checagens de falhas nos ns.
Interface de seqenciamento:
Interface de busca estendida, provendo informaes mais acuradas sobre o
escalonamento das tarefas;
Interface de controle estendida para permitir maior controle sobre as tarefas,
seus atributos e execuo;
Permite a obteno de dados estatsticos de tarefas j executadas.
Escalabilidade:
Servidor de monitoramento;
Capacidade de trabalhar com cluster muito grande (acima de 15TeraFlops e
2500 processadores);
Capacidade de trabalhar com um grande volume de tarefas (acima de 2000

G UIA DE C LUSTER 12.3 - MAUI
processos);
Capacidade de suportar grande nmero e tamanho de mensagens de servi-
dores.
Usabilidade:
Mecanismo de log mais completo;
Logs com caractersticas de leitura mais simples.
12.3 MAUI
Stio:
http://www.clusterresources.com/pages/products/
maui-cluster-scheduler.php
MAUI um avanado escalonador de tarefas com um grande conjunto de carac-

tersticas desenvolvidas especialmente para plataformas de computao de alto
desempenho (HPC). Ele usa polticas de escalonamento agressivas para otimizar
a utilizao de recursos e minimizar o tempo de resposta (execuo) das tarefas
(job). Simultaneamente, prov ferramentas de controle administrativas sobre os
recursos e o volume de tarefas sendo executadas, permitindo uma grande capa-
cidade de configurao em diversas reas como: priorizao de tarefas, seqen-
ciamento, alocao, distribuio de cargas e polticas de reserva de recursos.
MAUI foi projetado com base em experincias coletivas dos maiores e mais avan-
ados centros de HPC do mundo. Ele prove ferramentas que estes centros pre-
cisavam para controlar, rastrear e otimizar o uso de seus recursos. Uma coleo
extensiva de estatsticas e ferramentas de perfil, modo de teste de operao e
um avanado simulador de caractersticas que permite a checagem de ambientes
de produo, para saber se todas as alteraes de configuraes foram feitas de
forma segura.

G UIA DE C LUSTER 12.4 - C RONO
12.4 Crono
Crono um gerenciador de recursos livre e otimizado para pequenos e mdios

clusters baseados em sistema GNU/Linux [289]. O Crono suporta batch jobs e
possui um escalonador otimizado, baseado em caractersticas presentes em al-
guns outros gerenciadores de recursos.
As principais caractersticas do Crono so:
Possui um bom nvel de configurao, permitindo a criao de grupos e o

controle de acesso a nvel de usurio e de grupos;
Um pequeno nmero de linhas de cdigo (comparado a outras solues

existentes), o que torna mais simples a adaptao do sistema por usurios
especialistas;
Suporte a scripts de pr e ps processamento de requisio, que torna o

sistema mais flexvel para atender demanda especfica de usurios;
Permite modo de alocao de espao compartilhado (os ns so alocados

exclusivamente para o usurio) e de tempo compartilhado (onde usurios
podem compartilhar um mesmo n);
Suporte a clusters heterogneos em nmero de processadores e em arqui-

tetura, tornando possvel, por exemplo, que existam em um mesmo cluster
mquinas de arquitetura Intel x86, x86-64 e Itanium;
Suporte integrao com o OurGrid, permitindo que facilmente ns do

cluster sejam utilizados por usurios de grids. Este suporte pode ser para
acesso dedicado ou no-dedicado. No primeiro, ns do cluster so aloca-
dos para usurios da grade e ficam disponveis pelo tempo de alocao. No
segundo, todos os ns no alocados a usurios locais so cedidos ao grid e
removidos do mesmo to logo sejam solicitados por usurios locais (isto ,
usurios que possuem direito de acesso ao cluster).

Captulo 13
Grids Computacionais
Grids Computacionais surgiram em meados da dcada de 90 com a promessa de viabilizar

a execuo de aplicaes paralelas em recursos geograficamente dispersos e pertencentes
a mltiplas organizaes. Tal proposta tinha dois grandes apelos. O primeiro era o de
fornecer uma plataforma muito mais barata para execuo de aplicaes distribudas (que
os supercomputadores paralelos). O segundo era possibilitar (atravs da aglomerao de
recursos dispersos) a execuo de aplicaes paralelas em uma escala simplesmente impos-
svel em um nico supercomputador. Com a evoluo da tecnologia de grids percebeu-se
que a composio automtica de um conjunto de recursos para servir uma aplicao criava
a oportunidade de oferecer servios sob demanda. Assim, surgiu a idia de um Grid
onde seja possvel prover sob demanda qualquer servio computacional (no somente ser-
vios para computao de alto desempenho). Como conseqncia, as tecnologias de Grids
Computacionais se fundiram com Web Services e se posicionaram como uma tecnologia
fundamental para computao no sculo XXI. O texto a seguir descreve a evoluo dos
Grids Computacionais, cobrindo as principais tecnologias existentes, e apresentando os
aspectos importantes para criao de Grids de Servios genricos, bem como caractersti-
cas especficas de Grids para alto desempenho.
13.1 Introduo
Grids Computacionais so atualmente uma das reas mais quentes da Com-

putao. O que comeou em universidades e institutos de pesquisa ganhou o

G UIA DE C LUSTER 13.1 - I NTRODUO
mundo empresarial e hoje faz parte da estratgia de corporaes como IBM, HP,
Sun, NEC, Microsoft e Oracle. Em suma, temas relacionados a Grids Computaci-
onais figuram hoje como um assunto em moda.
Porm, o que afinal vem a ser um Grid Computacional? A viso original estabe-
lece uma metfora com A Rede Eltrica (The Electric Grid) [183]. A Rede Eltrica
disponibiliza energia eltrica sob demanda e esconde do usurio detalhes como
a origem da energia e a complexidade da malha de transmisso e distribuio.
Desta forma, se temos um equipamento eltrico, simplesmente o conectamos na
tomada para que ele receba energia. O Grid Computacional (The Computational
Grid), portanto, seria uma rede na qual o individuo se conecta para obter Servios
Computacionais que agregam recursos sob demanda (ex.: ciclos, armazenamento,
software, perifricos, etc). A Figura 13.1 ilustra esta idia.
Figura 13.1: Acesso transparente a servios e recursos
Um sistema que fornea servios computacionais sob demanda de forma transpa-

rente certamente desejvel para vrias instituies e aplicaes. Note que, para
muita gente, a Internet este sistema. De fato, para aqueles cujas necessidades
de processamento so satisfeitas por um computador pessoal, a Internet atende
os requisitos bsicos de um Grid Computacional. Por exemplo, quando usamos
home banking, nosso computador pessoal, uma srie de roteadores e os computa-

dores do nosso banco se agregam sob demanda para nos fornecer um servio de
forma transparente.
importante esclarecer que no queremos, com o exemplo anterior, sugerir que

um Grid Computacional o mesmo que a Internet. De uma certa forma, o Grid
a evoluo da Internet. A idia que qualquer servio computacional possa
ser obtido no Grid, e que se possa agregar automaticamente vrios servios mais
simples, gerando um um servio mais sofisticado. Voltando ao nosso exemplo de
home banking, este servio pensado para viabilizar o acesso de um humano (um
cliente do banco) seus dados bancrios. muito complicado usar o servio em
outros contextos, como parte de uma aplicao maior, que por exemplo acesse os
dados bancrios na preparao do imposto de renda.
Grids Computacionais nasceram da comunidade de Processamento de Alto De-

sempenho, motivada pela idia de se utilizar computadores independentes e am-
plamente dispersos como plataforma de execuo de aplicaes paralelas [183].
Porm, com a evoluo da pesquisa sobre Grids Computacionais e tecnologias
utilizadas pela indstria para computao distribuda, houve naturalmente uma
convergncia entre o mundo acadmico e empresarial. Assim, a idia prover
uma infraestrutura que viabilize servios sob demanda, permitindo uma maior
colaborao entre vrias instituies, atravs do compartilhamento de seus servi-
os e recursos, e utilizando mecanismos que facilitem a interoperabilidade.
Os atrativos desta idia incluem a possibilidade de fornecimento de qualquer ser-

vio computacional sob demanda, o qual pode ser composto dinamicamente por
outros servios e agregar recursos localizados em vrias instituies distintas e
geograficamente dispersas. Alm disso, os recursos podem ser alocados em uma
quantidade enorme (e.g. centenas de milhares de computadores conectados via
Internet) e por um custo muito menor do que alternativas tradicionais (baseadas
em supercomputadores paralelos).
Um aspecto importante, que deve ser considerado, o fato de mesmo havendo a

convergncia entre tecnologias para alto desempenho e da indstria, existe uma
leve diferena entre Grids que fornecem e que no fornecem um servio de execuo
remota. Esse servio fundamental para a comunidade de alto desempenho, uma
vez que permite a execuo de aplicaes paralelas no Grid. Mas, concebvel
imaginar Grids mais comerciais, onde o foco o acesso e composio de servios
sob demanda, que funcionem perfeitamente bem sem disponibilizar o servio de

execuo remota.
O servio de execuo remota crucial porque ele introduz importantes desafios

para infraestrutura do Grid. Os Grids que fornecem execuo remota tendem
a ser mais complexos, pois ao permitir uma maior flexibilidade aos clientes do
servio, que podem converter o servio de execuo remota em qualquer servio,
deve-se preocupar com questes como segurana (ex.: como proteger o recurso
de aplicaes maliciosas?) e escalonamento (ex: que servio de execuo mais
adequado para a aplicao?).
Neste texto, usaremos Grids de Servios quando estivermos tratando questes per-
tinentes a qualquer Grid, disponibilize ele o servio de execuo remota, ou no.
Usaremos Grids para Alto Desempenho quando estivermos tratando das questes
adicionais que so introduzidas pelo servio de execuo remota. Assim, nesta
nossa terminologia, todo Grid para Alto Desempenho um Grid de Servios,
embora o contrrio no seja necessariamente verdade.
Outra forma de ver Grids encar-los como plataformas de computao distri-

buda. H vrias plataformas tradicionais de computao distribuda, seja de
propsito mais comercial (CORBA, DCOM, etc), seja de propsito mais tcnico
(clusters, supercomputadores paralelos). Para esclarecer um pouco mais a dife-
rena entre os Grids e outras plataformas de computao distribuda, podemos
citar algumas caractersticas que so intrnsecas aos Grids. De modo geral, os
Grids so mais distribudos, diversos e complexos que outras plataformas. As-
pectos que evidenciam esta distribuio, diversidade e complexidade so:
Heterogeneidade: Os componentes que formam a infraestrutura tendem ser

extremamente heterogneos. Ou seja, importante ter em mente que qual-
quer soluo para Grids Computacionais dever lidar com recursos de v-
rias geraes, softwares de vrias verses, instrumentos e servios dos mais
variados tipos.
Alta disperso geogrfica: Essa caracterstica se refere a escala que um Grid

pode atingir. Nesse sentido, Grids podem ter escala global, agregando ser-
vios localizados em vrias partes do planeta.
Compartilhamento: Em contraste com solues space-shared, um Grid no

pode ser dedicado a uma aplicao de forma exclusiva por um determinado

perodo de tempo. Isso tem impacto no desenvolvimento de aplicaes que

executam sobre a infraestrutura de um Grid Computacional.
Mltiplos domnios administrativos: Grids congregam recursos de vrias insti-

tuies. Sendo assim, alm da heterogeneidade mencionada anteriormente,
possvel tambm a existncia de vrias polticas de acesso e uso dos servi-
os, de acordo com as diretrizes de cada domnio que faz parte do Grid.
Controle distribudo: Tipicamente no h uma nica entidade que tenha po-

der sobre todo o Grid. Isso um reflexo da disperso dos componentes do
Grid, pois cada instituio pode implementar sua poltica em seus recur-
sos locais, mas no interfere diretamente na implementao de polticas no
acesso aos servios de outras instituies participantes.
Note que esta discusso prope um conceito e no uma definio para Grid
Computacional. Uma plataforma de fornecimento de servios computacionais
que apresenta as caractersticas acima listadas certamente um Grid. Contudo,
a ausncia de alguma das caractersticas no deve automaticamente desqualifi-
car uma determinada plataforma como Grid. Por outro lado, o leitor deve estar
atento que o termo Grid Computacional pode ser usado to e somente como fer-
ramenta de marketing [180]. Devido a sua popularidade e a seu impacto posi-
tivo, o termo Grid Computing tem sido utilizado de forma muito liberal, como no
passado outros termos j foram (como: Orientao a Objetos, Sistemas Abertos,
Downsizing, Reengenharia, Internet/Intranet/Extranet, entre outros).
Portanto, com o objetivo de desmistificar e posicionar os esforos atuais na con-

cretizao da viso original dos Grids Computacionais, discutiremos vrios as-
pectos importantes dos Grids de Servios, e tambm das questes particulares
dos Grids para Alto Desempenho, que incluem servios de execuo remota.
Este texto est organizado da seguinte forma: na sesso 13.2 apresentamos os

Grids de Servios, suas principais caractersticas, benefcios, desafios que tais ca-
ractersticas sugerem e os investimentos de padronizao. Na sesso 13.3 sero
apresentados as questes exclusivas a Grids para Alto Desempenho, que envol-
vem o desenvolvimento de um ambiente de execuo de aplicaes paralelas em
escala global. Na sesso 13.4 faremos um estudo de caso com algumas solues
para Grids Computacionais. Finalmente, na sesso 13.6 concluiremos uma breve
discusso sobre as tendncias em Grids Computacionais.

G UIA DE C LUSTER 13.2 - G RIDS DE S ERVIOS
13.2 Grids de Servios
Antes de se iniciar uma discusso sobre aspectos relacionados a Grids de Servi-

os necessrio definir o que um servio. Na teoria econmica, um servio
uma mercadoria imaterial provida por uma entidade legal (provedor) para satisfazer as
necessidades de outra entidade (cliente) [190].
Utilizando essa definio como analogia, consideramos como servio computaci-

onal qualquer recurso (ou outro servio) que possa ser acessado remotamente e
descrito atravs de uma interface (por um provedor), a qual pode ser interpretada
de forma automtica (por um cliente). Desta forma, tudo pode ser considerado
como servio, desde que exista a possibilidade de se criar uma abstrao que for-
nea essa interface.
Neste captulo discutiremos as tecnologias que permitem o desenvolvimento de

infraestruturas baseadas em servios computacionais, bem como aspectos impor-
tantes para a implementao dessas infraestruturas. Em seguida, abordaremos
tambm padres emergentes para Grids de Servios.
13.2.1 Acesso a Servios
De modo geral, a idia por trs de uma arquitetura baseada em servios compu-
tacionais no uma novidade. Ou seja, o grande interesse atual da comunidade
cientfica e da indstria por arquiteturas orientadas a servios, bem como o cres-
cimento de esforos nessa rea se deve, em grande parte, pelo sucesso e amplo
uso de Web Services [168, 350].
Portanto, possvel citar vrias tecnologias anteriores a Web Services, que em

sua essncia forneciam mecanismos para a criao de arquiteturas baseadas em
servios. Por exemplo, em um sentido amplo, podemos considerar CORBA [35]
e RMI (Remote Method Invocation) [21] como tecnologias que permitem a constru-
o de infraestruturas de computao distribuda baseadas em servios. Todavia,
aspectos como a ampla disperso de recursos, falta de controle central e vasta
diversidade de clientes, as quais so caractersticas intrnsecas dos Grids, intro-
duzem um requisito que se torna fundamental: interoperabilidade.

G UIA DE C LUSTER 13.2.1 - A CESSO A S ERVIOS
Em RMI o provedor do servio (um objeto remoto) requer, invariavelmente, que

seu cliente, no s seja Java, como tambm conhea antecipadamente (em tempo
de compilao) qual sua interface. Para tornar um servio acessvel, o prove-
dor deve registr-lo no RMI registry [21]. O servio identificado e includo em
um catlogo mantido pelo registro. Do outro lado, o cliente usa uma URL para
acessar o registro e obter uma referncia para um dos servios publicados em seu
catlogo. O acesso ao servio feito usando a referncia obtida atravs do RMI
registry. A Figura 13.2 ilustra o acesso a um servio usando RMI.
Figura 13.2: Acessando um servio usando RMI
Ao contrrio de RMI, CORBA oferece maior interoperabilidade entre clientes e

provedores. Isso possvel pois servios CORBA so descritos atravs de uma
linguagem de descrio (Interface Definition Language - IDL), que independente
da linguagem em que o servio e cliente so implementados. Esse aspecto torna
CORBA mais flexvel que RMI, pois permite que o cliente e o servio sejam im-
plementados em linguagens diferentes. Por exemplo, podemos ter um cliente
desenvolvido em C++ e um servio escrito em Java.
Em CORBA, um servio acessado de forma semelhante a RMI. A diferena subs-

tancial est na existncia de uma entidade chamada Object Request Broker (ORB).
A Figura 13.3 ilustra a operao de acesso a um servio na plataforma CORBA.
Note que o ORB responsvel por prover transparncia no acesso do cliente ao
servio. Assim, tanto a localizao e implementao do servio, quanto do cliente
tornam-se transparentes para ambos. Essa transparncia na localizao torna-se
vivel pelo uso do protocolo IIOP (Internet Inter Orb Protocol), que prov o trans-

G UIA DE C LUSTER 13.2.2 - D ESCOBERTA DE S ERVIOS
porte das invocaes do cliente ao servio.
Figura 13.3: Acessando um servio usando CORBA [14]
Apesar das vantagens de CORBA, alguns autores defendem que CORBA falhou
na garantia de interoperabilidade entre os ORBs, o que tornaria a plataforma
mais amplamente utilizada. O argumento que a competio entre os desen-
volvedores de ORB s se tornou acirrada acarretando problemas de interoperabili-
dade [199].
Por outro lado, Web Services surgiu como uma nova tecnologia para computa-
o distribuda, que aproveitou vrios padres j bem estabelecidos como seu
alicerce. O primeiro, e talvez maior, contraste entre Web Services e CORBA a
camada de transporte utilizada por cada uma das plataformas. Enquanto CORBA
baseado no protocolo IIOP, Web Services aproveita o protocolo HTTP para en-
vio de mensagens entre cliente e provedor. A Figura 13.4 ilustra como ocorre a
comunicao entre o cliente e um Web Service. Note que a interface do servio
descoberta em tempo de execuo. Aps obteno da referncia para o servio,
o cliente pode iniciar a comunicao com o servio atravs do envio de mensa-
gens.
13.2.2 Descoberta de Servios
Apesar de ser possvel que clientes acessem servios diretamente (sem envolver
um catlogo), permitir que os servios sejam descobertos dinamicamente fun-
damental para construir uma infraestrutura de servios sob demanda.
Sendo assim, em Grids computacionais fundamental que seja possvel desco-

Figura 13.4: Interao entre cliente e provedor (Web Services) [345]
brir os servios existentes em uma infra-estrutura que podem atender a demanda

de uma determinada aplicao. A idia que um servio de descoberta funcione
como as pginas amarelas de um catlogo telefnico, que permitem os usurios
da rede telefnica encontrarem prestadores de servios, a partir de alguns cri-
trios, como classificao da atividade, localizao do estabelecimento e outras
informaes divulgadas no catlogo.
Em sistemas CORBA por exemplo, o servio de descoberta se chama Trader [35].

Ele possui o cadastro dos objetos distribudos do sistema com suas respectivas
propriedades, e permite que qualquer objeto consulte este cadastro para encon-
trar objetos cujas propriedades atendam um determinado critrio de pesquisa.
Se em um sistema CORBA, restrito a uma nica organizao, um servio de des-

coberta importante, o que dizer de sistemas em Grid, que executam em um
ambiente multi-institucional. Eles so fundamentais para que seja possvel com-
partilhar recursos e servios computacionais em escala global. No contexto da
Computao em Grid, os recursos compartilhados podem ser ciclos de CPU, es-
pao em disco, software, sensores, dentre outros, que podem tornar-se acessveis
na rede como Web Services [39].
Neste sentido, existem vrias propostas de se construir um servio de descoberta

de Web Services. O servio de descoberta mais discutido e incorporado ar-
quitetura WSRF [40] do servio UDDI (Universal Description, Discovery, and
Integration) [27], j adotado por vrios produtos voltados para a tecnologia de
Web Services, de grandes empresas como Sun Microsystems, Microsoft e Oracle.
O UDDI ele mesmo um Web Service que permite a formao de um catlogo

global de todos os Web Services compartilhados na Internet. Este catlogo or-

ganizado em ns e registros. Um n um servidor UDDI onde esto os dados dos
servios cadastrados. Um conjunto de ns chamado de registro, e cada n s
pode pertencer a um nico registro.
Um registro pode ser privado, pblico ou afiliado. Os registros privados, ou cor-

porativos, so aqueles que guardam informaes de Web Services internos de
uma empresa, protegido por um firewall, que devem ter seu acesso restrito s
aplicaes da empresa. J os registros afiliados compartilham e trocam seus da-
dos de forma controlada com outros registros, baseado em acordos entre as insti-
tuies envolvidas. Seus Web Services esto disponveis apenas a usurios auto-
rizados. Um exemplo de registros afiliados o de Web Services sendo utilizados
por aplicaes de empresas de uma holding. Cada empresa poderia ter seu pr-
prio registro e eles juntos formarem um grupo de registros afiliados, permitindo
que as aplicaes de cada empresa localizasse os servios umas das outras. H
ainda os registros pblicos que, como o prprio nome sugere, guardam informa-
es sobre Web Services que podem ser acessados livremente na Web. Os dados
mantidos pelos registros pblicos podem ser compartilhados ou transferidos li-
vremente entre eles. Um exemplo de um registro pblico o UBR (UDDI Business
Registry), hoje estruturado em quatro ns, sob responsabilidade das empresas
IBM, Microsoft, NTT Communications e SAP. Qualquer entidade pode publicar
ou consultar servios nesses ns, gratuitamente. O UBR est para os Web Servi-
ces assim como o Google est para as pginas Web. O consumidor de servios
que quiser localizar servios na rede, provavelmente ter mais sucesso em sua
busca se consultar o UBR. Igualmente, o provedor que quiser ter seus servios
encontrados ter que public-los no UBR.
No UDDI, cada Web Service tem cadastrado um documento WSDL (Web Service
Description Language, baseado em XML) que descreve o servio oferecido, for-
necendo informaes que ajudam a localiz-lo no catlogo, assim como estabe-
lecer a forma correta de invoc-lo. O cadastro e a consulta deve ser feito pelas
aplicaes atravs de APIs que se comunicam com os ns centrais utilizando o
protocolo SOAP.
Alguns trabalhos criticam a natureza centralizada do UDDI, dizendo que, apesar

de ser adotado como padro na arquitetura WSRF, ele no oferece uma soluo
eficiente, escalvel e tolerante a falhas como servio de descoberta de Web Ser-

vices, da forma como vem sendo implementado. Eles argumentam que, por ser
centralizado, o UDDI apresenta baixo desempenho na atualizao e consulta dos
registros, que essa degradao tende a ser maior quanto maior for a quantidade
de servios catalogados e que um ponto nico de falha.
Uma alternativa ao UDDI o WSPDS (Web Service Peer-to-peer Discovery Ser-

vice) [75]. O WSPDS baseia-se no fato de que os Web Services podem formar uma
rede peer-to-peer, onde os peers se conhecem e podem trabalhar de forma coope-
rativa, para atender as consultas. A idia que quando um peer precise realizar
uma consulta na rede, ele a repasse primeiramente a seus peers conhecidos. Es-
tes por sua vez, propagam a consulta aos peers de sua prpria lista, at um limite
definido por contadores de propagaes contido nas mensagens trocadas. Cada
peer que recebe a mensagem, realiza a consulta em sua lista local e retorna os
resultados positivos para o peer original da consulta, que entregue ao execu-
tor da consulta. Esse protocolo empregado por aplicaes populares como o
Gnutella [32], na consulta de arquivos compartilhados por seus usurios.
O WSPDS traz algumas vantagens e desvantagens em relao ao UDDI. Ele de

fato uma soluo mais tolerante a falhas, j que no possui pontos nicos de fa-
lha. No h servidores, responsveis por atender s consultas por servios. A
escalabilidade tambm um ponto forte seu, j que o aumento da quantidade de
servios no influencia o desempenho das consultas. No entanto, no h uma ga-
rantia de que um servio que atenda aos critrios de uma consulta seja localizado.
Um resultado de consulta negativo no necessariamente significa a ausncia de
servios na rede que satisfaam os critrios de pesquisa. Pode acontecer que os
peers que participam da pesquisa no tenham contato com o servio que atende
consulta.
Uma alternativa hbrida entre as duas abordagens a de federaes de registros

UDDI [26]. A idia fazer com que os registros estejam conectados entre si, em
uma rede peer-to-peer. Desta forma, quando uma consulta for feita a um registro
e este no puder atend-la, ele repassar a mesma consulta a outros registros, e
assim sucessivamente, de forma semelhante a como ocorre no WSPDS. Cada re-
gistro realizar a consulta em seus prprios ns e devolver ao registro original
da consulta os resultados, que sero entregues ao executor da consulta. Esta abor-
dagem foi originalmente adotada pelo servio Trader do CORBA. Ela aumenta a
robustez, tolerncia a falhas, eficincia e escalabilidade do servio de descoberta.

G UIA DE C LUSTER 13.2.3 - A UTENTICAO E A UTORIZAO
A verso 3.0 do UDDI j fornece suporte para mltiplos registros e permite a for-
mao das federaes. Com o crescimento esperado do uso de Web Services e
conseqentemente do servio UDDI, este parece ser o caminho natural de evolu-
o do servio de descoberta.
13.2.3 Autenticao e Autorizao
Na Seo 13.2.1 descrevemos como ocorre o acesso a servios usando vrias tec-
nologias para computao distribuda. importante ressaltar que apresentamos
uma simplificao da realidade. Pois, devido ampla distribuio e existncia
de mltiplos domnios administrativos, o acesso aos recursos que compem um
Grid no to simples.
Quando comparamos o Grid com outras plataformas fica claro que a ampla dis-
perso de servios e clientes cria a necessidade de um maior controle sobre o
acesso aos servios e recursos. Por exemplo, em uma rede local, ao efetuar login
no sistema, o usurio identificado e autenticado, em geral, para todos os recur-
sos conectados e servios disponveis na rede. Pois, normalmente se mantm um
cadastro de usurios que vlido para toda a rede.
J em Grids, necessria uma forma de acesso para cada recurso (ou subcon-
junto de recursos, quando estes compartilham do mesmo cadastro de usurios).
Obviamente, tal forma de acesso tem que oferecer garantias sobre autenticao
dos usurios, caso contrario os administradores de sistema no sero simpticos
idia de permitir que usurios de outros domnios tenham acesso aos recursos
locais atravs dos servios presentes naquele domnio administrativo.
As iniciativas atuais de Grids tm tratado esse problema atravs do uso de esque-

mas baseados em chaves pblica e privada, bem como certificados digitais. Desta
forma, cada domnio administrativo pode manter sua poltica local de autentica-
o e autorizao, e exporta um servio que cuida da autenticao e autorizao
do acesso de clientes externos aos seus servios.
Como veremos em mais detalhes na Seo 13.4.1 e na Seo 13.4.3, algumas infra-
estruturas possuem uma camada que fornece uma infraestrutura de segurana
para que seja possvel autenticar e autorizar o acesso e uso de servios do Grid,

G UIA DE C LUSTER 13.2.4 - P RIVACIDADE DE D ADOS
enquanto outras usam certificados digitais, no apenas para autenticar usurios,

mas tambm para prover comunicao segura entre os clientes e os servios.
13.2.4 Privacidade de Dados
Alm das demandas por segurana dos provedores de servios, os clientes des-
ses servios tambm impem necessidades de segurana. Logo, alguns clientes
requerem privacidade no tratamento dos seus dados enviados para os servios.
Desta forma, desejvel que apenas o cliente e o servio que recebe os dados
tenham acesso a eles. Vrias aplicaes necessitam esse nvel de privacidade.
Garantir esse aspecto algo desafiador em um ambiente amplamente distribudo
e dinmico como o Grid.
A necessidade de proteo dos dados existe por dois motivos. O primeiro se re-
fere a possibilidade de acesso no autorizado a informaes confidenciais. O se-
gundo aspectos, est relacionado a possibilidade de sabotagem, onde outra apli-
cao modifica os dados a serem processados a fim de manipular os resultados
que sero obtidos com aquela computao.
A Entropia [30] prov mecanismos de criptografia para garantir a segurana dos

dados da aplicao nos recursos do Grid. Assim, apenas o proprietrio do dado
armazenado poder acessar e manipular os dados usando sua chave de cripto-
grafia [114]. O problema que possvel que algum possa modificar o cdigo
da Entropia para obter as chaves armazenadas por eles.
Assim, ainda existem muitos problemas em aberto nessa rea. Hoje, instituies
que necessitam de um servio de execuo distribudo e tm como requisito prin-
cipal privacidade no utilizam uma infraestrutura to dispersa quanto o Grid.
Essas aplicaes executam em ambientes controlados e proprietrios onde a pri-
vacidade pode ser garantida. Um exemplo disso foi a infraestrutura montada
pela HP para prover a renderizao das imagens do filme Sherek 2 [34].

G UIA DE C LUSTER 13.2.5 - C OMPOSIO DE S ERVIO
13.2.5 Composio de Servio
Em nossa sociedade, estamos bem acostumados com a prestao de servios por

parte de empresas, profissionais e governo. Muitas vezes, para executar um ser-
vio, um prestador de servio torna-se cliente de outros prestadores, sem que
seus clientes tomem conhecimento disso. Uma agncia de turismo, por exemplo,
vende pacotes de viagem e para prestar este servio, contrata servios de compa-
nhias areas, centrais de intercmbio estudantil, hotis, empresas de aluguel de
carro, etc. Para o cliente que compra o pacote, o servio prestado por uma nica
entidade. como se a venda da passagem area, de quartos em hotis, aluguel
de carro, fossem feitos pela prpria agncia de turismo. Todavia, muito difcil
uma agncia de viagens se estruturar e funcionar, tendo que ser responsvel por
tantas atividades, que no so sua atividade fim. O servio torna-se mais caro
e complexo de ser administrado. A estratgia adotada geralmente terceirizar
estas atividades. Assim, a venda do pacote de viagem torna-se uma composio de
servios prestados por diversas entidades.
Da mesma forma, em Grids Computacionais, os servios podem ser compostos

por outros servios. A composio de servios traz uma srie de benefcios para
a computao distribuda. Os dois principais so: i) Abstrao da complexidade
do servio para o cliente; ii) Reutilizao das funcionalidades implementadas por
outros servios.
Para o cliente, quanto mais complexo for o servio, menos envolvido ele desejar
estar. No exemplo citado anteriormente, sem o trabalho das agncias de turismo,
o preparo de uma viagem implicar em muito mais trabalho para o cliente. A
venda de pacotes tursticos simplifica muito o trabalho dos que pretendem tirar
frias. Da mesma forma, no mundo da computao, quanto mais compostos fo-
rem os servios, mais simples e alto nvel deve ser programao das aplicaes
clientes.
O segundo aspecto positivo da composio de servio a reutilizao de cdigo.

Um servio j desenvolvido e disponvel no sistema rede pode ser usado na com-
posio de novos servios. Desta forma, seu cdigo no tem que ser reimple-
mentado. Um exemplo real so os Web Services fornecidos pela Receita Federal,
que permitem consulta e validao de CPF e CNPJ. Estas funcionalidades esto
presentes em diversas aplicaes por todo o pas. Como servios, elas podem

G UIA DE C LUSTER 13.2.5 - C OMPOSIO DE S ERVIO
ser utilizadas por essas diversas aplicaes, evitando que sejam implementadas
novamente.
Entretanto, a composio traz tambm desafios. Um deles como um servio

composto pode garantir qualidade, uma vez que ele no o responsvel direto
por executar todas as suas etapas. Como no mundo real, para os clientes que
usam um servio, como se ele fosse nico, prestado por um nico provedor. No
exemplo usado anteriormente, a responsabilidade por atender aos requisitos do
cliente que compra o pacote de viagem do provedor do servio. O servio da
agncia teria que atender os requisitos de segurana, tempo de processamento,
limites de custo informados pelo cliente, para o qual, a composio do servio
invocado transparente.
Para a especificao apropriada de servios compostos, precisamos de modelos

que definam as vrias caractersticas da composio. Ou seja, a identificao dos
possveis componentes, quando, como e em que condies sero usados, regras
para seu funcionamento, dentre outras. Assim, um modelo de composio possui
as seguintes dimenses:
Modelo de componentes: define a estrutura dos componentes que fazem parte

da composio;
Modelo de orquestrao: especifica a ordem em que cada componente dever

ser acionado, e sobre quais condies;
Dados e modelo de acesso aos dados: especifica a estrutura dos dados usados
na composio, bem como a forma de acesso a eles;
Modelo de seleo de servio: especifica como o usurio pode selecionar

cada servio, e o papel que cada componente desempenha na composio;
Transaes: especifica o tratamento de transaes pela composio - o que

deve ser feito quando uma falha ocorre durante a execuo de uma transa-
o.
Na tentativa de suprir a demanda por linguagens e ferramentas especialmente

voltadas para a composio de servios, vrios trabalhos foram desenvolvidos
at ento, por exemplo, XLANG [361], WSFL [255] e BPEL4WS [131]. Apesar do

G UIA DE C LUSTER 13.2.6 - D ISPONIBILIZAO DE S ERVIOS
alto nvel da especificao e riqueza de detalhes que estas linguagens permitem

alcanar nas especificaes, elas tm sofrido vrias crticas da comunidade.
A principal crtica diz respeito ao fato de que ao especificar a composio de ser-

vios, necessrio conhecer antecipadamente todos os servios que fazem parte
da composio, bem como a ordem e condies em que cada tarefa deve ser exe-
cutada. Isto torna impossvel montar novas composies em tempo de execu-
o, automaticamente. Isto abre uma lacuna na rea, criando uma demanda por
modelos de descrio e ferramentas mais ricos, para que se possa superar este
obstculo, e oferecer servios cada vez mais complexos e dinmicos.
13.2.6 Disponibilizao de Servios
Para que Grids sejam teis, preciso que eles existam, preciso cri-los. Ou
seja, aps ser possvel descobrir os servios, eles devem ser agregados para criar
uma infraestrutura de servios computacionais, que permita a execuo de apli-
caes. Esta sentena bastante bvia. Contudo, ela levanta alguns problemas
tcnicos no-triviais. Suponha que duas instituies A e B decidem formar um
Grid, unificando seus recursos e fornecendo melhores servios computacionais a
seus usurios. Porm, como incentivar domnios administrativos a participarem
do Grid com seus servios e recursos?
Suponha que A tem mais que o dobro dos recursos de B. Um compartilhamento

igualitrio seria prejudicial a A, que ento relutaria em formar um Grid com B.
Por outro lado, assuma que A no pode fornecer acesso a seus recursos durante
o expediente bancrio (10:00 as 16:00). Como se pode perceber, o contrato entre
A e B para compartilhamento de recursos e construo de um Grid comum pode
ser algo bastante sofisticado. Tal sofisticao gera uma pergunta bvia de como
as regras de compartilhamento acordadas sero implementadas e policiadas.
Se a criao de um Grid entre duas instituies pode oferecer tal complexidade,

imagine a criao de Grids envolvendo centenas ou milhares de entidades. A
abordagem que vem sendo sugerida para este problema a utilizao de mode-
los econmicos para guiar esse processo de criao de Grids [98, 118]. A idia
bsica a construo de um mercado computacional onde as diversas entidades
envolvidas no Grid possam trocar recursos. O aspecto mais atraente desta abor-

dagem que acordos de compartilhamento sofisticados no so mais necessrios.

Recursos so comprados e vendidos de forma independente, sem um supervisor
onisciente do mercado. Desta forma, entidades podem decidir independente-
mente quando comprar ou vender recursos. Inicialmente, a moeda utilizada ser
provavelmente algum dinheiro virtual que daria apenas poder de compra de re-
cursos computacionais. Entretanto, razovel imaginar que o cmbio entre este
dinheiro virtual e dinheiro real logo se torne possvel, incentivando a criao de
empresas que forneam servios computacionais sob demanda.
importante destacar trs elementos que formam a base desta economia: pro-
vedores de servios, consumidores de servios e os servios propriamente ditos.
Note que provedor e consumidor so papis que podem ser assumidos concor-
rentemente. Abaixo listamos e discutimos brevemente alguns modelos econmi-
cos [99]:
Commodity Market: Provedores divulgam de forma competitiva seus servi-

os e os respectivos preos. Consumidores decidem baseado no custo/be-
nefcio qual provedor iro contratar.
Posted Price Market Model: Muito similar ao Commodity Market, a diferena

consiste no tempo que dura a oferta de preos feita pelos provedores. Nesse
caso, as ofertas duram mais tempo.
Bargaining Model: Provedores e consumidores negociam preos dos servi-

os, onde cada um tenta maximizar o resultado de acordo com seus ob-
jetivos. Neste caso as negociaes so entre pares Consumidor-Provedor.
Sendo assim, os consumidores tomam a deciso (contratar ou no) baseado
em seus objetivos locais.
Tender/Contract Net: Uma espcie de licitao. Um convite de oferta parte

do consumidor para vrios provedores que respondem com seus preos e
condies de servio. O consumidor decide qual contratar fazendo a anlise
do custo do servio e das condies de atendimento.
Auction: Neste modelo os provedores enviam convites de oferta aos con-

sumidores. Os consumidores pode modificar sua oferta (em incrementos
positivos). A negociao finaliza quando os consumidores param de efe-
tuar ofertas.

Bid based Proportional Resource Share: Neste modelo a quantidade de recursos

/ servios alocada aos consumidores de forma proporcional ao valor de
suas ofertas.
Community/Coallition/Bartering Model: A idia bsica deste modelo a cri-

ao de um ambiente cooperativo de compartilhamento de recursos. Ou
seja, provedores que contribuem tero garantida a possibilidade de consu-
mir quando necessitarem.
A seguir, apresentaremos estratgias usadas para incentivar a participao de en-

tidades no Grid. A idia promover a agregao de recursos de vrios domnios
administrativos, com o intuito de formar um Grid que beneficie os clientes de
cada domnio.
GRACE - Grid Architecture for Computational Economy
desejvel que uma soluo para o problema de incentivo participao no Grid

fornea flexibilidade no que se refere as polticas de compartilhamento de recur-
sos. Ou seja, necessria a existncia de mecanismos que garantam o comparti-
lhamento de recursos de forma escalvel. Alm disso, dever ser possvel para o
cliente expressar seus requisitos, bem como os provedores expressarem as condi-
es de fornecimento servio.
Assim, acompanhando a metfora usada inicialmente baseada na idia do The

Electric Grid, que serviu para traar os objetivos dos Grids Computacionais, a
aplicao de modelos econmicos tambm se baseia no fato que j existem abor-
dagens baseadas em leilo para o mercado de energia eltrica [25].
Portanto, a introduo de modelos de compartilhamento mais sofisticados, base-

ados em economia, promete uma infraestrutura mais flexvel e poderosa para o
compartilhamento de recursos e construo de Grids. Um exemplo de investi-
mento nessa rea de pesquisa o GRACE (GRid Architecture for Computational
Economy) [99]. A arquitetura do GRACE foi pensada levando em considerao os
requisitos que uma infraestrutura de economia computacional deve preencher.
Logo, inspirado pela idia de mercados, os princpios de projeto da arquitetura
so:

1. Um diretrio onde seja possvel publicar informaes sobre as entidades

que formam o Grid (i.e. consumidores e provedores), tal como descrito na
Seo 13.2.2.
2. Modelos para o estabelecimento de valores para os recursos / servios.
3. Esquemas de cotao e mecanismos de oferta de servios.
4. Modelos econmicos e protocolos de negociao de contratao de servios
5. Mediadores que atuam como reguladores e estabelecem valores para os re-

cursos / servios, criam moeda padro e ajudam na resoluo de impasses
entre os negociadores.
6. Mecanismos para contabilizao, cobrana e pagamento.
Para tanto, a arquitetura do GRACE composta dos seguintes componentes: a)

Grid Resource Broker (e.g., Nimrod/G); b) Grid Resource and Market Informa-
tion Server; c) Grid Open Trading Protocols and API; d) Trade Manager; e) Grid
Trade Server.
O Resource Broker funciona como um procurador do usurio (ou de sua aplica-

o) perante ao Grid. Sendo assim, o Resource Broker desempenha atividades
que permitem a execuo da aplicao do usurio atendendo seus requisitos (e.g.
menor preo pelo servio de execuo). Alm disso, um aspecto importante que
o Resource Broker exibe o Grid para o usurio como um conjunto unificado de
recursos, essa abstrao facilita a viso do usurio sobre o ambiente.
Certamente, o Resource Broker depende da existncia de vrios servios. Por

exemplo, servios de informao sobre os recursos que so oferecidos no Grid,
seus preos e condies de uso. Esse servio fornecido pelo Grid Resource and
Market Information Server, o qual utiliza como base o servio de descoberta de
servios do Globus (i.e. MDS [181]).
Alm de obter informao sobre servios disponveis e suas cotaes, necessrio

que haja um padro (um protocolo bem conhecido pelo cliente e pelo provedor
de servios) para a negociao. Logo, a arquitetura do GRACE possui um conjunto
de protocolos e uma API que define regras e o formato para troca de comandos
entre o cliente GRACE (i.e. Trade Manager) e o provedor do servio (Trade Server).

Vale mencionar que o Trade Manager uma parte importante do Resource Broker,
pois tem o papel de guiar a seleo dos recursos que a aplicao necessita para
atingir seus objetivos. Por outro lado, o Trade Server o agente de negociao do
lado do provedor, sua funo maximizar a utilizao do recursos e o lucro do
provedor.
Portanto, a negociao entre os Trade Managers (clientes) e os Trade Servers (pro-

vedores) ocorrer de acordo com algum modelo econmico. Uma das imple-
mentaes possveis do GRACE utiliza como broker o Nimrod/G [102]. O mo-
delo econmico implementado foi o Posted Price Market Model descrito anterior-
mente [99]. Nesse caso, os vrios Trade Servers do sistema devem divulgar seus
preos, de forma a atrair consumidores, esperando que os Trade Managers requi-
sitem o servio, tomando como base para escolha a comparao de preos entre
os preos divulgados.
Rede de Favores
Apesar ser bastante pertinente, a introduo de modelos econmicos a fim de

controlar o compartilhamento de recursos entre sites, um grande nmero de apli-
caes, que igualmente necessitam de uma infraestrutura de recursos/servios
computacionais de larga escala, no requerem um contrato to forte entre clientes
e provedores, como as providas por uma arquitetura baseada em modelos econ-
micos. Ao manter o foco neste tipo de aplicao, se torna possvel desenvolver
uma soluo prtica que pode ser usada efetivamente por uma comunidade de
usurios.
Claramente, estamos apresentando um dilema entre ter uma infraestrutura de

escopo mais geral, porm mais complexa o que dificultaria sua implantao efe-
tiva, e uma infraestrutura mais simples, o que facilitaria sua implantao, po-
rm com um escopo mais restrito. Pensando nisso, foi desenvolvida a soluo
OurGrid [36, 61]. A idia ser uma soluo simples que permita a criao de
Grids Computacionais que fornecem poder computacional seguindo a poltica
best-effort. O foco est em aplicaes Bag-of-Tasks (i.e. aquelas aplicaes cujas
tarefas so independentes), com essa reduo de escopo foi possvel ter um Grid
Computacional em produo [117]. O OurGrid formado por trs componentes:
MyGrid Broker [120], OurGrid Peer [61] e uma soluo de Sanboxing baseado no

Xen [81].
OurGrid explora a idia de que um Grid composto de vrios sites que tm o

interesse em trocar favores computacionais entre si. Portanto, existe uma rede peer-
to-peer de troca de favores que permite que os recursos ociosos de um site seja
fornecido para outro quando solicitado. Para manter o equilbrio do sistema, em
uma situao de conteno de recursos, sites que doaram mais recursos (quando
estes estavam ociosos) devero ter prioridade junto comunidade quando solici-
tar recursos.
A Figura 13.5 ilustra a idia da rede de favores, onde cada peer controla um con-
junto de recursos de um site. Ao surgir uma demanda interna por recursos que o
peer de um determinado site no consegue suprir, este PEER ir fazer requisies
comunidade. A idia que os peers utilizem um esquema de prioridade base-
ado em quanto eles consumiram dos outros. Os resultados mostram que haver
um compartilhamento justo de recursos entre os peers [60].
Figura 13.5: Ilustrao da arquitetura OurGrid [36]

G UIA DE C LUSTER 13.2.7 - PADRONIZAO
13.2.7 Padronizao
Nesta seo exploraremos um pouco mais a viso que motiva boa parte da pes-
quisa sobre Grids Computacionais atualmente, orientao a servios. Neste sen-
tido, faremos tambm um breve histrico sobre os padres para arquiteturas ba-
seadas em Grid Services e qual o estado atual desses esforos.
A viso
A experincia prtica adquirida no desenvolvimento dos Grids de alto desem-

penho tornou possvel identificar os problemas que dificultam a implantao de
uma infraestrutura com esta escala e complexidade. A questo central que deve
guiar o desenvolvimento de tecnologias para Grids Computacionais pode ser en-
tendida como sendo a integrao de recursos e servios distribudos de forma
transparente e eficiente. Assim, foi identificado que este requisito motiva tanto a
comunidade cientfica como a indstria.
Portanto, do lado acadmico, a crescente necessidade de cooperao cientfica

entre grupos geograficamente distribudos, atravs do compartilhamento de re-
cursos e servios, do outro lado a indstria que tem como necessidade a integra-
o de sistemas comerciais. Essas demandas impulsionaram a convergncia de
tecnologias de ambas as comunidades.
Como resultado, os Grids evoluram para utilizar uma abordagem orientada a

servios baseado em padres e tecnologias para Web Services. Partindo de um
conjunto de servios bsicos, como autenticao e transferncia de dados, a idia
a construo de Grids que forneam de servios sob demanda.
OGSA / OGSI /Globus 3.x
No intuito de realizar a viso da orientao a servios, houve um convergncia

de tecnologias da rea de computao de alto desempenho e de padres bem
consolidados pela indstria, isso ocorreu atravs da unio de tecnologias e con-
ceitos Grids com web services [250]. A partir disto foi definida uma arquitetura de

servios bsicos para a construo de uma infraestrutura de Grids Computacio-

nais baseados em Servios. Esta arquitetura foi denominada Open Grid Services
Architecture (OGSA) [184, 53].
A definio do OGSA contempla a idia de interconexo de sistemas e a criao

de ambientes virtuais multi-institucionais. Alm disso, os recursos que podem
ser agregados ao Grid so representados por servios e estes servios so cha-
mados de Grid Services [184]. Os grid services so essencialmente web services que
seguem convenes estabelecidas na especificao da OGSA e suportam interfaces
padronizadas para garantir algumas operaes adicionais, como gerenciamento
do ciclo de vida do servio.
As interfaces padres definidas pelo OGSA facilitam a virtualizao de recursos e

servios. Isso possibilita o uso de vrios tipos de recursos de forma transparente.
Outra vantagem da virtualizao que interfaces padres permitem um baixo
acoplamento entre o cliente e o provedor do servio. Esse baixo acoplamento
facilita a mudana na implementao dos servios sem causar, necessariamente,
mudanas na implementao do cliente, bem como o inverso.
Aps a definio do modelo da arquitetura e identificao de servios bsicos

atravs do padro OGSA foi necessria a especificao do comportamento desses
servios. Sendo assim, o passo seguinte foi a especificao dessa infraestrutura
servios bsicos, no intuito de permitir a implementao do modelo da arquite-
tura definida pela OGSA. A nova especificao foi denominada Open Grid Services
Infrastructure (OGSI) [368] e tem o objetivo de definir as interfaces bsicas e os
comportamentos de um Grid Service [53]. OGSI a materializao da arquitetura
definida pelo padro OGSA, pois os servios especificados servem como base para
construo dos Grids. Em termos prticos, a especificao OGSI define:
Um conjunto de extenses para a linguagem WSDL (Web Service Descrip-

tion Language).
Padres de estrutura e operao, em WSDL, para representao pesquisa e

atualizao de dados sobre os servios.
As estruturas Grid Service Handle e Grid Service Reference usados para refe-
renciar um servios.

Formato para mensagens que indicam falhas, sem modificar o modelo de

mensagens de falha da linguagem WSDL.
Conjunto de operaes que permitem a criao e destruio de Grid Ser-

vices. Esse conjuntos de operaes devem fornecer destruio explcita de
servios, como tambm garbage collection (destruio implcita do servio).
Conjunto de operaes para criao e uso de colees de Web Services por

referncia.
Mecanismos que permitam notificao assncrona, caso haja mudana em

valores dos elementos de dados dos servios.
O Globus Toolkit 3.0 (GT3) [181] forneceu a primeira implementao da OGSI 1.0
em julho de 2003. No intuito de esclarecer melhor o papel de OGSA, OGSI e Glo-
bus, Figura 13.6 ilustra como essas entidades se relacionam formando um cenrio
de padres e implementaes de tecnologias para Grids de Servio.
Figura 13.6: Relacionamento entre OGSA, OGSI e Globus [345]
Note, portanto, que Grid Service um conceito central no relacionamento destas

tecnologias e padres. Assim, OGSA define Grid Services, OGSI especifica o com-
portamento de Grid Services, Web Services so estendidos para se tornar Grid
Services e Globus 3 implementa a especificao OGSI. Alm disso, Globus prov
servios bsicos necessrios para a construo de servios de mais alto nvel (e.g.
servios de autenticao via GSI).

WSRF /Globus 4.x
Uma vez que toda a base de Grid Services surgiu das tecnologias para Web Ser-
vices, alguns aspectos da especificao OGSI precisavam ser refinados devido a
evoluo da arquitetura Web Services.
O principal ponto de crtica foram os mecanismos de endereamento para os ser-

vios (i.e. Grid Service Handler e Grid Service Reference). Nesse caso, WS-Addressing
surgiu pra fornecer um mecanismo de endereamento independente da camada
de transporte [132].
Alm disso, outras caractersticas de OGSI precisavam ser modificadas para acom-
panhar a evoluo da tecnologia Web Service, melhorando assim a especificao
OGSI . Assim, WSRF (Web Service Resource Framework) basicamente o resultado
do refinamento de OGSI no intuito de aproveitar a existncia dos novos padres
que surgiram para para Web Services (e.g. WS-Addressing, WS-Notification) e
assimilar a demanda da comunidade Web Services.
O primeiro efeito do refatoramento foi a diviso de OGSI em vrias especificaes

separadas, porm agrupadas em uma famlia. A idia reduzir a complexidade
de uma especificao longa, que dificulta a adoo incremental de funcionalida-
des.
Outra medida importante foi a recuperao da compatibilidade com as ferramen-

tas existentes para XML e Web Services, pois OGSI usa GWSDL, a qual prov acrs-
cimos WSDL 1.1 que estaro disponveis na WSDL 1.2/2.0. Ao contrrio de OGSI,
ao invs de estender a definio de portType WSDL 1.1, ou mesmo esperar pelo
da nova verso WSDL 2.0, WS-Resource Framework utiliza puramente WSDL 1.1,
o que garante compatibilidade com as ferramentas existentes para Web Services.
Alguns entusiastas da rea de Web Services, em geral, argumentam que Web Ser-
vices no devem manter estado ou ter instncias. Ou seja, OGSI modela um recurso
que mantm estado como um Web Service que encapsula o estado do recurso.
WS-Resource Framework modifica esse modelo para criar uma distino expl-
cita entre servio e entidades que mantm estado e so manipuladas atravs do
servio. Esta composio denominada WS-Resource pelo padro WSRF, que in-
troduz a idia de recursos que mantm estados e podem ser acessados atravs de

G UIA DE C LUSTER 13.3 - G RIDS PARA A LTO D ESEMPENHO
Web Services via o uso convencional de WS-Addressing.
Portanto, em linhas gerais, a evoluo de OGSI obedeceu trs fases de forma in-
cremental. A primeira, a introduo do conceito de WS-Resource. Em seguida a
diviso de funcionalidades em vrias especificaes melhorando a compatibili-
dade com ferramentas usadas para Web Service. Finalmente, uma melhoria nos
mecanismos de notificao.
O padro WSRF deve se materializar, de forma estvel, atravs do lanamento

do Globus 4. Atualmente, Maro de 2005, o Globus se encontra na verso 3.9.5,
que apesar de instvel j incorpora vrias das funcionalidades contempladas no
padro WSRF. Por exemplo, o GRAM do Globus 3, ser substitudo pelo WS-
GRAM , o qual segue as especificaes definidas na famlia de padres WSRF.
13.3 Grids para Alto Desempenho
Neste captulo os Grids Computacionais so apresentados como uma plataforma

de execuo para aplicaes paralelas. Sendo assim, faremos comparaes com
plataformas de execuo convencionais. Em seguida definiremos quais so os
tipos de aplicaes paralelas mais adequadas para executar em um Grid Compu-
tacional. Finalmente, apresentaremos dois estudos de caso.
13.3.1 Plataformas para Processamento Paralelo
Uma aplicao paralela composta por vrias tarefas. As tarefas que compem
uma aplicao paralela executam em vrios processadores, caracterizando desta
forma o paralelismo da execuo da aplicao e conseqente reduo no seu
tempo de execuo. Os processadores usados por uma determinada aplicao
constituem a plataforma de execuo da aplicao.
Plataformas de execuo de aplicaes paralelas variam em diversos aspectos,

dos quais destacamos conectividade, heterogeneidade, compartilhamento, ima-
gem do sistema e escala.

G UIA DE C LUSTER 13.3.1 - P LATAFORMAS PARA P ROCESSAMENTO PARALELO
Conectividade diz respeito aos canais de comunicao que interligam os pro-

cessadores que compem a plataforma de execuo. Atributos que definem
a conectividade de uma plataforma so a topologia, largura de banda, la-
tncia e compartilhamento.
Heterogeneidade trata das diferenas entre os processadores, que podem ser

de velocidade e/ou arquitetura.
Compartilhamento versa sobre a possibilidade dos recursos usados por uma

aplicao serem compartilhados por outras aplicaes.
Imagem do sistema se refere existncia de uma viso nica da plataforma,

independente do processador sendo utilizado. Por exemplo, todos os pro-
cessadores da plataforma enxergam o mesmo sistema de arquivos?
Escala estabelece quantos processadores tem a plataforma.
Entender as diferenas entre plataformas fundamental porque cada aplicao

paralela tem uma srie de requisitos, que podem ser melhor ou pior atendidos
por uma dada plataforma. Em princpio, procuramos executar uma aplicao pa-
ralela em uma plataforma adequada s caractersticas da aplicao. Por exemplo,
considere conectividade, um aspecto em que plataformas diferem consideravel-
mente. Obviamente, para obter boa performance de uma aplicao paralela cujas
tarefas se comunicam e sincronizam freqentemente, necessitamos utilizar uma
plataforma de execuo com boa conectividade.
Podemos agrupar as plataformas de execuo hoje existentes em quatro grandes

grupos: SMPs, MPPs, NOWs e Grids. SMPs (ou multiprocessadores simtricos)
so mquinas em que vrios processadores compartilham a mesma memria.
Multiprocessadores possibilitam um fortssimo acoplamento entre os processa-
dores e executam uma nica cpia do sistema operacional para todos os proces-
sadores. Portanto, eles apresentam uma imagem nica do sistema e excelente
conectividade. Todavia, multiprocessadores apresentam limitaes em escalabi-
lidade, raramente ultrapassando algumas dezenas de processadores. Multipro-
cessadores so relativamente comuns no mercado e vo desde mquinas bipro-
cessadas Intel at grandes servidores como os da srie HP 9000. A Figura 13.7
ilustra a arquitetura de um multiprocessador.
MPPs (ou processadores maciamente paralelos) so compostos por vrios ns

Figura 13.7: Arquitetura multiprocessada
(processador e memria) independentes,interconectados por redes dedicadas e

muito rpidas. MPPs incluem supercomputadores paralelos como o IBM SP2 e
Cray T3E, como tambm clusters de menor porte montados pelo prprio usu-
rio. Tipicamente cada n roda sua prpria cpia do sistema operacional, mas uma
imagem comum do sistema implementada atravs da visibilidade dos mesmos
sistemas de arquivo por todos os ns. O MPP controlado por um escalonador
que determina quais aplicaes executaro em quais ns. Ou seja, no se pode
utilizar um n que no tenha sido alocado aplicao pelo escalonador. Isto
possibilita dedicar parties (um conjunto de ns) s aplicaes, permitindo que
estas no precisem considerar compartilhamento. Mas, uma vez que aplicaes
executam em parties dedicadas, pode acontecer que no haja ns suficientes
para executar uma aplicao assim que ela submetida. Neste caso, a aplica-
o espera em uma fila at que os recursos que solicitou estejam disponveis. A
Figura 13.8 exemplifica a arquitetura de um MPP.
Figura 13.8: Arquitetura de um MPP

N O Ws (ou redes de estaes de trabalho) so simplesmente um conjunto de es-

taes de trabalho ou PCs, ligados por uma rede local. N O Ws so arquitetu-
ralmente semelhantes aos MPPs. Ambas plataformas so formadas por ns que
agregam processador e memria. Uma diferena entre N O Ws e MPPs que os
ns que compem uma MPP tipicamente so conectados por redes mais rpidas
que as que conectam os ns de N O Ws. Mas a principal diferena entre ambas
arquiteturas que N O Ws no so escalonadas de forma centralizada. Isto , em
uma N O W, no h um escalonador para o sistema como um todo. Cada n tem
seu prprio escalonador local. Como resultado, no h como dedicar uma par-
tio da N O W a uma s aplicao paralela. Assim, uma aplicao que executa
sobre a N O W deve considerar o impacto da concorrncia por recursos por parte
de outras aplicaes sobre sua performance. A Figura 13.9 mostra esquematica-
mente uma N O W.
Figura 13.9: Arquitetura de uma N O W
Grids so o passo natural depois dos N O Ws no sentido de mais heterogeneidade

e maior distribuio. Os componentes de um Grid no se restringem a proces-
sadores, podendo ser SMPs e MPPs como tambm instrumentos digitais. Grids
tipicamente no fornecem uma imagem comum do sistema para seus usurios.
Componentes do Grid podem variar drasticamente em capacidade, software ins-
talado, sistemas de arquivo montados e perifricos instalados. Alm disso, os
componentes de um Grid tipicamente estar sobre controle de diferentes entida-
des e, portanto, em domnios administrativos diversos. Conseqentemente, um
dado usurio pode ter acesso e permisses bastante diversas nos diferentes com-
ponentes de um Grid. Obviamente, o Grid no pode ser dedicado a um usurio,
embora seja possvel que algum componente possa ser dedicado (um MPP, por

exemplo). importante salientar que uma aplicao que executa sobre o Grid
deve estar preparada para lidar com todo este dinamismo e variabilidade da pla-
taforma de execuo, adaptando-se ao cenrio que se apresenta com o intuito de
obter a melhor performance possvel no momento. A Figura 13.10 exemplifica
um possvel Grid, composto por um MPP e computadores de vrios tipos co-
nectados via Internet. Note que um destes computadores realiza instrumentao
(no exemplo, atravs de um microscpio), enquanto outro computador dispe de
grande capacidade para armazenamento de dados.
Figura 13.10: Arquitetura de um Grid Computacional
A Tabela 13.1 resume as caractersticas das plataformas de execuo de aplica-

es paralelas discutidas aqui. Mantenha em mente, entretanto, que a Tabela 13.1
descreve caractersticas tpicas dos diferentes tipos de plataformas de execuo.
Certas plataformas podem apresentar caractersticas arquiteturais adicionais que
impactam na performance das aplicaes paralelas que nela executam. Por exem-
plo, alguns MPPs oferecem suporte de hardware a memria compartilhada, atra-
vs de uma tecnologia denominada DSM (Distributed Shared Memory), o que

melhora o desempenho de aplicaes baseadas em memria compartilhada. Uma

vez que Grids so o nosso foco neste texto, caso o leitor queira mais detalhes so-
bre plataformas de execuo de aplicaes paralelas tradicionais (SMPs, MPPs e
N O Ws) sugerimos a leitura do trabalho de De Rose e Navaux [314].
Mesmo quando no h distines arquiteturais, diferentes plataformas do mesmo

tipo podem diferir consideravelmente. Em particular, um Grid pode diferir radi-
calmente de outro. Por exemplo, considere o TeraGrid [38], o SETI@home [59] e
o PAU [117].
O TeraGrid um Grid que interliga 10 centros de supercomputao norteameri-

canos atravs de canais de altssima velocidade (40 GigaBits/segundo). Cada um
dos centros possui milhares de processadores dedicados ao TeraGrid, gerando
um poder agregado de aproximadamente 20 TeraFlops. O SETI@home, por outro
lado, utiliza a capacidade computacional ociosa de computadores que se juntam
voluntariamente ao sistema atravs da instalao do software cliente do projeto.
Em Maro de 2005, SETI@home contava com aproximadamente 5.3 milhes de
processadores espalhados em 226 pases. O PAU, por sua vez, tem uma escala
intermediria, pois congrega 10 domnios administrativos espalhados pelo Brasil
(ver http://pauastatus.lsd.ufcg.edu.br) e tem como infraestrutura o OurGrid, que se
baseia em uma rede peer-to-peer para o compartilhamento de recursos entre os
sites (i.e. Rede de Favores [61]). Apenas considerando essas breves descries
notvel a diferena entre os trs Grids. Outro aspecto interessante de se verificar
que apesar do TeraGrid congregar um nmero semelhante de sites, comparado
ao PAU, o TeraGrid tem muito mais recursos PAU.
O conceito de acoplamento do Grid (i.e. quo prximos esto seus componentes)

fundamental para compreendermos quais aplicaes podem executar eficiente-
mente em um Grid. Note que acoplamento tem uma relao com conectividade.
Voltando ao exemplo acima, o SETI@home e o PAU tm seus focos em aplica-
es fracamente acopladas, enquanto o TeraGrid pode propiciar condies para
execuo eficiente de aplicaes fortemente acopladas).

G UIA DE C LUSTER 13.3.2 - E XECUO R EMOTA
SMP MPP NOW Grid

Conectividade excelente muito boa boa regular/ruim
Heterogeneidade nula baixa mdia alta
Compartilhado no no sim sim
Imagem nica comum comum mltipla
Escala 10 1.000 1.000 100.000
Tabela 13.1: Comparao entre as plataformas de execuo para aplicaes paralelas
13.3.2 Execuo Remota
Na Seo 13.3.1 apresentamos o Grid como uma plataforma de execuo de apli-

caes paralelas. Alm disso, apresentamos o que diferencia os Grids de outras
plataformas mais tradicionais para processamento de alto desempenho. Vale res-
saltar que o componente fundamental dos Grids para Alto Desempenho o ser-
vio de execuo remota. Este servio responsvel por qualificar o grid como pla-
taforma de execuo de aplicaes paralelas.
Um Grid que fornece servios de execuo remota possui vrias vantagens. Uma
delas a possibilidade de converter este servio genrico de execuo de aplica-
es em qualquer outro servio mais especfico. Por exemplo, oferecer um servio
de processamento de imagens que utiliza vrias instncias do servio de execuo
remota dispersos por todo Grid.
Em contrapartida, a introduo dessa flexibilidade adquirida atravs do forneci-

mento de um servio de execuo genrico, que pode ser convertido em outros
servios mais especficos, aumenta a complexidade da infraestrutura. Portanto,
novas questes devem ser consideradas para que seja possvel fornecer um ser-
vio de execuo remota eficiente. Por exemplo, quais servios de execuo re-
mota, disponveis no Grid, devem ser usados, de forma a obter uma execuo
eficiente da aplicao de processamento de imagens? Como proteger o servio
de aplicaes maliciosas? Discutiremos vrias dessas questes nas prximas se-
es.
13.3.3 Escalonamento
Um dos aspectos mais importantes para o desenvolvimento dos Grids a im-

plementao de estratgias de alocao de recursos para as vrias aplicaes que
usam a infraestrutura. Sendo assim, tanto possvel pensar em escalonamento

G UIA DE C LUSTER 13.3.3 - E SCALONAMENTO
de aplicaes, bem como escalonamento de recursos. Em geral, os objetivos des-

sas duas vises contrastam entre si. A primeira procura melhorar o desempenho
da aplicao. A segunda busca aumentar a utilizao dos recursos. Nesta seo
discutiremos essas duas vises sobre escalonamento, bem como heursticas de
escalonamento de aplicao.
Escalonamento de aplicao vs. Escalonamento de recurso
Tradicionalmente, h um escalonador que controla os recursos do sistema (i.e.,

no h como usar os recursos sem a autorizao do escalonador). Por exemplo,
o sistema operacional controla o computador no qual roda, decidindo quando
e aonde (no caso de multiprocessadores) cada processo executa. Chamaremos
estes escalonadores de escalonadores de recursos. Uma caracterstica importante
dos escalonadores de recurso que eles recebem solicitaes de vrios usurios
e, portanto, tem que arbitrar entre estes vrios usurios o uso dos recursos que
controlam.
Devido grande escala, ampla distribuio e existncia de mltiplos domnios

administrativos, no possvel construir um escalonador de recursos global para
Grids. Uma razo para isto que sistemas distribudos que dependem de uma
viso global coerente (necessria ao controle dos recursos) apresentam problemas
de escalabilidade. Alm disso, muito difcil (seno impossvel) convencer os
administradores dos recursos que compem o Grid a abrir mo do controle de
seus recursos.
Assim sendo, para utilizar recursos controlados por vrios escalonadores de re-
curso distintos, algum tem que (i) escolher quais recursos sero utilizados na
execuo da aplicao, (ii) estabelecer quais tarefas cada um destes recursos rea-
lizar, e (iii) submeter solicitaes aos escalonadores de recurso apropriados para
que estas tarefas sejam executadas. Esta o papel do escalonador de aplicao. Es-
calonadores de aplicao no controlam os recursos que usam. Eles obtm acesso
a tais recursos submetendo solicitaes para os escalonadores que controlam os
recursos.
Ou seja, em um Grid, as decises de escalonamento so divididas em duas ca-

madas, com parte da responsabilidade pelo escalonamento sendo transferida dos

Figura 13.11: Ilustrao de um cenrio composto de vrios escalonadores
escalonadores de recurso para o nvel de aplicao. A Figura 13.11 ilustra um

cenrio de escalonamento em um Grid Computacional.
As decises tomadas pelo escalonador de aplicaes (quais recursos sero uti-

lizados e quais tarefas cada um destes recursos realizar) so normalmente ba-
seadas em um modelo do desempenho da aplicao e em dados sobre o estado
atual dos vrios recursos que formam o Grid [89, 111, 329, 382, 381, 167]. Por-
tanto, escalonadores de aplicao tm que conhecer detalhes das aplicaes que
escalonam, i.e. eles so construdos com uma aplicao (ou classe de aplicaes)
em mente. Alm disso, escalonadores de aplicao normalmente precisam sa-
ber quanto tempo cada recurso vai levar para processar uma dada tarefa. Sem
esta informao, difcil escolher os melhores recursos a utilizar, como tambm
determinar qual tarefa alocar a cada um desses recursos. Para obter tal informa-
o, foram desenvolvidos sistemas que monitoram e prevem o comportamento
futuro de diversos tipos de recursos [262, 392]. Este esquema de obteno de in-
formao baseado em monitorao tem se mostrado eficaz quando os recursos
monitorados so redes TCP/IP ou computadores compartilhados no tempo, mas
ainda h questes quanto a escalabilidade dos sistemas de monitorao [189].

Previso de Desempenho
Apesar de serem teis e ajudarem no desenvolvimento de heursticas de escalo-

namento eficientes, as infraestruturas de monitorao e previso de desempenho
tm um desafio imposto pela escala que um Grid computacional pode alcanar.
Alm disso, devido a descentralizao do controle sobre os recursos no Grid,
possvel que por questes de segurana alguns domnios administrativos no
adotem a implantao de sistemas de monitorao, a fim de fornecer informa-
es de previso de desempenho para escalonadores de aplicao.
Mesmo assim, pensando na possibilidade de prover um melhor desempenho no

escalonamento de aplicaes que alguns sistemas de previso de desempenho fo-
ram desenvolvidos. Como consequncia vrias heursticas foram desenvolvidas
dependendo das informaes fornecidas por estas infraestruturas de monitora-
o [111, 89].
Uma servio utilizado por vrias heursticas de escalonamento o Network We-

ather Service (NWS) [392]. O NWS um sistema que monitora e dinamicamente
prov estimativas de desempenho de recursos computacionais (ex.: processado-
res e rede). O processo de monitorao feito atravs de sensores que mede
periodicamente o estado dos recursos. As informaes coletadas pelos sensores
podem ser requisitadas diretamente pelas heursticas, que utilizam essa informa-
o para melhorar a eficincia do escalonamento gerado.
Alm da informao sobre o desempenho de um recurso, em um dado instante,

fornecido pelos sensores, as heursticas podem fazer uso de previses de desem-
penho que so geradas pelo NWS a partir do histrico obtido com a monitorao.
Assim, atravs do uso de mtodos numricos (e.g. regresso linear) as informa-
es armazenadas sobre o desempenho dos recursos so processadas para gerar
estimativas do desempenho que os recursos podem oferecer em um determinado
intervalo.
Considerando o benefcio que uma arquitetura de monitorao, que fornea in-

formaes sobre os recursos do Grid, o Global Grid Frum [196] mantm grupos
de trabalho discutindo sobe questes relacionadas definio de uma arquitetura
de monitorao. Estas discusses so, em geral, baseadas na experincia obtida
de investimentos j feitos por vrios grupos, como NWS [392] e Autopilot [311],

dentre outros trabalhos [377, 338, 363]. A arquitetura proposta baseada na idia
de produtor/consumidor de eventos disparados pelos sensores que monitoram os
recursos [378]. Apesar da evoluo conceitual que a padronizao pode introdu-
zir na rea de previso de performance para sistemas distribudos, muito ainda
tem que ser feito para se ter uma infraestrutura amplamente disponvel.
A seguir descreveremos algumas situaes onde um servio de previso de de-

sempenho extremamente til, bem como estratgias eficientes de escalona-
mento de aplicao que no dependem de informao sobre os recursos do Grid
nem da aplicao.
Aplicaes Fortemente Acopladas
Jacobi AppLeS [89] um exemplo interessante, primeiro por ter introduzido a

idia de escalonamento de aplicaes e tambm por fornecer uma soluo de
escalonamento para uma aplicao bem conhecida (i.e. Jacobi).
Jacobi um mtodo usado para resolver a aproximao por diferenas finitas da

equao de Poisson e portanto aplicvel a problemas que envolvem fluxo de
calor, eletrosttica e gravitao. Alm de ser interessante por si s, Jacobi pode
ser visto como uma instncia de uma importante classe de aplicaes paralelas:
aplicaes fortemente acopladas de paralelismo em dados.
Jacobi AppLeS um escalonador para Jacobi 2D. Em Jacobi 2D, o domnio do

problema discretizado em uma matriz bidimensional. Em cada iterao, cada
elemento da matriz atualizado com a mdia dos seus quatro vizinhos. Jacobi
termina por convergncia, isto , quando uma iterao altera muito pouco os
elementos da matriz.
Quando Jacobi executado em um MPP (Massive Parallel Processor), a matriz bidi-

mensional tipicamente dividida em ambas as dimenses, gerando submatrizes
de igual tamanho. Cada submatriz ento alocada a um processador. A cada
iterao, portanto, necessrio comunicao entre processadores para troca das
fronteiras das submatrizes. A Figura 13.12 mostra a distribuio de dados entre 4
processadores de um MPP alocados para executar Jacobi. Como, em um MPP, os
processadores so idnticos e dedicados, esta simples estratgia de alocao de

trabalho balanceia a carga entre os processadores, garantindo bom desempenho.
Em um Grid, entretanto, processadores e canais de comunicao so heterog-

neos. Alm disso, outras aplicaes esto concorrendo pelos mesmos recursos
(processadores e canais de comunicao) enquanto Jacobi executa. Conseqente-
mente, a estratgia descrita acima provavelmente vai produzir um desbalano de
carga, afetando o desempenho. Mais ainda, uma vez que as condies de carga
do Grid variam dinamicamente, o que uma boa diviso de carga vai variar a
cada execuo da aplicao. Finalmente, devido existncia de canais de comu-
nicao mais lentos e compartilhados com outras aplicaes, talvez no valha a
pena utilizar todos os processadores disponveis.
Figura 13.12: Jacobi executando em quatro processadores em um MPP
A soluo oferecida por AppLes Jacobi se baseia em trs elementos principais.

Primeiro, o escalonamento em si simplificado pela deciso de utilizar um par-
ticionamento unidimensional. Segundo, o escalonador se utiliza do NWS [392]
para obter previses de curto prazo da disponibilidade de cada processador e da
latncia e banda da comunicao entre quaisquer dois processadores. Terceiro,
o escalonador dispe de um modelo de performance da aplicao, que usado
para avaliar suas decises. Este modelo o seguinte:
Ti = Ai Pi + Ci (13.1)
Ti o tempo para o processador i executar uma iterao.
Ai a rea da submatriz alocada ao processador i.

Pi o tempo que o processador i leva para computar um elemento.
Ci o tempo que o processador i leva para comunicar suas fronteiras.
Note que Pi e Ci so estimados com base nos dados fornecidos pelo NWS.
O escalonamento propriamente dito comea ordenando os processadores por

uma distncia especfica da aplicao (que cresce quadraticamente com a dife-
rena de velocidade dos processadores e linearmente com a diferena de suas
capacidades de comunicao). Uma vez os processadores ordenados, tenta-se
iterativamente uma soluo com os n primeiros processadores, at que a soluo
com n 1 processadores se mostre mais rpida, ou at que no haja mais proces-
sadores. Naturalmente, o tempo de uma iterao estimado como o maior Ti de
todos os processadores. Fixados n processadores, a soluo de escalonamento
obtida dividindo a matriz proporcionalmente a Pi .
Por exemplo, suponha que o Grid tem quatro processadores: P0 , P1 , P2 e P3 . As-

suma ainda que P0 e P1 tem o dobro da velocidade de P2 e P3 , que P1 tem uma
outra aplicao rodando e s poder dedicar 50% de seu poder computacional a
aplicao, que P3 est conectado a uma rede que vivencia intenso trfego e que
sua comunicao est ordens de grandeza mais lenta que entre os demais proces-
sadores. Uma vez que P 3 est se comunicando muito lentamente, o AppLeS no
vai utiliz-lo para esta execuo. Note que esta deciso no descarta a possibi-
lidade que P3 venha a ser usado em uma futura execuo da aplicao, quando
as condies da rede forem diferentes. Note tambm que, embora P1 seja duas
vezes mais rpido que P2 , uma vez que s 50% de P1 est disponvel, P1 e P2 so
idnticos para a aplicao (pelo menos nesta execuo). A Figura 13.13 mostra o
resultado que o AppLeS Jacobi produziria neste cenrio.
Devemos salientar que um aspecto importante para o bom funcionamento do Ja-

cobi AppLeS o tempo relativamente curto de execuo da aplicao. O tempo de
execuo dos experimentos descritos em [89] da ordem de segundos, casando
perfeitamente com as previses de curto prazo do NWS. Para aplicaes que exe-
cutam por mais tempo (horas, digamos), seria necessrio prever a disponibili-
dade de recursos do Grid por prazos mais longos. Uma alternativa interessante
seria construir um escalonador que, alm do escalonamento inicial, continuasse
funcionando para reescalonar a aplicao caso as condies do Grid mudassem
consideravelmente [329]. Neste caso, naturalmente, a aplicao teria que ser es-

Figura 13.13: Escalonamento feito pelo Jacobi AppLes
crita para permitir tal reescalonamento, suportando a redistribuio de trabalho

durante a execuo.
Note que as previses de performance fornecidas pelo NWS so fundamentais

para o funcionamento do Jacobi AppLeS. De fato, a vasta maioria dos escalonado-
res de aplicao descritos na literatura [89, 111, 329, 382, 381, 167] utiliza alguma
forma de previso de performance. Infelizmente, h problemas em aplicar em
larga escala os sistemas de monitorao e previso existentes (como NWS [392] e
Remos [379]), especialmente quando se trata de prever o comportamento dos ca-
nais de comunicao, que crescem quadraticamente com o nmero de mquinas
do Grid. Em Francis, et al. [189] apresentada uma discusso sobre a dificuldade
e se construir um sistema escalvel para monitoramento de canais de comunica-
o.
Aplicaes Bag-of-Tasks
Apesar de ser possvel efetuar escalonamentos eficientes usando informao so-

bre o desempenho dos recursos, muitas aplicaes podem ser escalonadas de
forma eficiente sem o uso dessa informao. Isso possvel devido a algumas
caractersticas da aplicao. Em particular, aplicaes Bag-of-Tasks so aplica-
es que podem ser escalonadas sem o uso de informao dinmica sobre o Grid
(e.g. carga de CPU, largura de banda).
Como parte do projeto OurGrid [36], foram desenvolvidas duas heursticas de

escalonamento, o Work Queue with Replication (WQR) [299], um escalonador ca-

paz de obter boa performance para a aplicao no ambiente muito dinmico que
o Grid sem depender de previses de performance dos componentes do Grid.
Isto possvel devido a dois fatores fundamentais. Primeiro, WQR usa replicao
de tarefas para garantir a boa performance da aplicao. A idia utilizar alguns
ciclos extra para compensar pela falta de informao sobre o ambiente. Segundo,
WQR escalona aplicaes relativamente simples.
A idia aplicada na heurstica WQR bastante simples e ao mesmo tempo pode-

rosa. Uma fila de tarefas criada na submisso da aplicao. Sempre que h um
processador disponvel, uma tarefa enviada para este processador. Quando no
h mais tarefas para enviar (i.e. a fila de tarefas est vazia), uma das tarefas em
execuo replicada. Quando uma das replicas termina, as demais rplicas so
abortadas pelo escalonador. Para evitar o desperdcio de poder computacional,
estabelecido o mximo de replicas que uma tarefa pode ter. Nossos experimentos
mostraram um resultado bastante animador, eles indicam que grande parte do
ganho de desempenho obtido pelo WQR se manifesta com um grau de replicao
2.
Considere a Figura 13.14, que mostra o desempenho do WQR em comparao

com o Workqueue, o Sufferage [226] (um bom escalonador baseado em informa-
es sobre o Grid e sobre as tarefas), e com o Dynamic FPLTF (Dynamic Fastest
Processor to Largest Task First, outro bom escalonador que utiliza informaes
sobre o Grid e sobre as tarefas). Este resultado apresenta o tempo mdio obtido
pelos quatro algoritmos de escalonamento em funo da heterogeneidade das ta-
refas (quanto maior, mais heterogneo). Note que WQR foi executado trs vezes,
com replicao mxima de 2, 3 e 4 processadores. Observe tambm que Suf-
ferage e Dynamic FPLTF tiveram informao perfeita sobre o desempenho dos
recursos do Grid, bem como das tarefas que formam a aplicao, algo inatingvel
na prtica. Portanto, um excelente resultado o fato de WQR obter desempenho
comparvel com Sufferage e Dynamic FPLTF baseados em informao perfeita.
Obviamente, WQR consome mais ciclos que os algoritmos de escalonamento tra-

dicionais. A Figura 10 mostra o consumo adicional de CPU em funo da hetero-
geneidade das tarefas. Em situaes que a heterogeneidade de tarefas pequena,
este consumo no significativo, no ultrapassando 15%. Por outro lado, quando
tarefas so muito heterogneas, WQR desperdia uma quantidade considervel
de ciclos. De fato, o desperdcio pode chegar prximo a 100%. Entretanto, tal

Figura 13.14: Desempenho do WQR
problema pode ser controlado pela limitao do nmero mximo de replicas de

uma tarefa. Quando limitamos WQR a usar 2 replicas (WQR 2x), temos que o des-
perdcio de CPU fica sempre abaixo de 40%.
Aplicaes que Processam Grandes Quantidades de Dados
Apesar de WQR ser uma heurstica eficiente, ela apresenta uma limitao, o bom
desempenho alcanado apenas para aplicaes cpu-intensive. Ou seja, caso a
aplicao necessite processar grandes quantidades de dados, o que implicar em
muitas transferncias, a replicao pode no ter o mesmo efeito.
Uma grande parte das aplicaes Bag-of-Tasks necessitam processar grandes

quantidades de dados. Por exemplo, bioinformtica [54], Seti@Home [59], ren-
derizao de imagens [139, 254, 322, 207]. Sendo assim, uma heurstica de escalo-
namento que melhore o desempenho dessas aplicaes bastante relevante.
Felizmente, algumas aplicaes apresentam caractersticas que podem ser ex-

ploradas por heursticas de escalonamento para obter escalonamentos eficientes.

Figura 13.15: Desperdcio de ciclos com a replicao
Pensando nisso, foi desenvolvida a heurstica Storage Affinity[321], que explora

padres de reutilizao de dados e aplica replicao de forma semelhante a WQR.
Os padres de reutilizao foram classificados em dois tipos bsicos, inter-job e

inter-task. O padro inter-job determina que h reutilizao de dados entre exe-
cues sucessivas das aplicaes. Vale salientar que isso bastante comum em
aplicaes do tipo Parameter Sweep [113]. Outra situao de reutilizao captu-
rada pela definio do padro inter-task, aplicaes que apresentam esse padro
possuem reutilizao de dados durante um execuo. Por exemplo, aplicaes de
busca de seqncias de DNA, como o Blast [54], podem apresentar esse padro,
considerando que vrias seqncias podem ser pesquisadas em paralelo usando
o mesmo banco de dados de seqncias catalogadas.
Portanto, a idia explorar ambos os padres de reutilizao de dados para me-

lhorar o desempenho das aplicaes. Assim, Storage Affinity efetua o escalona-
mento baseado afinidade que as tarefas tm com os sites que formam o Grid. O
valor da afinidade determina quo prximo do site esta tarefa est. A semntica do
termo prximo est associada quantidade de bytes da entrada da tarefa que j
est armazenada remotamente em um dado site, ou seja, quanto mais bytes da
entrada da tarefa j estiver armazenado no site, mais prximo a tarefa estar do
site, pois poder iniciar sua execuo mais rapidamente. Assim, o valor da afini-
dade de uma tarefa com um site o nmero de bytes pertencentes entrada da tarefa,

Figura 13.16: Sumrio do desempenho de Storage Affinity comparado com outras heursticas
que j esto armazenados no site.
Note que Storage Affinity utiliza to somente as informaes sobre o tamanho e a

localizao dos arquivos de entrada. importante dizer que tais informaes po-
dem estar disponveis no instante do escalonamento sem dificuldade e perda de
preciso. Por exemplo, as informaes relacionadas aos dados de entrada de uma
tarefa podem ser obtidas atravs de requisies aos recursos de armazenamento
de dados. Mesmo que estes recursos no sejam capazes de responder s requi-
sies sobre quais elementos de dados eles armazenam e qual o tamanho de cada
elemento de dado, uma implementao alternativa da heurstica Storage Affinity
poderia facilmente manter um histrico das informaes sobre as transferncias
efetuadas para cada tarefa e assim possuir tais informaes.
Alm de aproveitar a reutilizao dos dados, Storage Affinity tambm trata a di-
ficuldade na obteno de informaes dinmicas sobre o Grid, bem como infor-
maes sobre o tempo de execuo das tarefas da aplicao. Para resolver este
problema, Storage Affinity efetua replicao de tarefas.
Storage Affinity executa em duas fases. Na primeira fase, cada tarefa associada a
um processador. A ordem de escalonamento determinada atravs do clculo do
valor da afinidade das tarefas. Aps determinar as afinidades, a tarefa que apre-
sentar o maior valor escalonada em um processador do site com o qual a tarefa
apresentou maior afinidade. A segunda fase consiste da replicao de tarefas.

Figura 13.17: Sumrio do desperdcio de recursos por Storage Affinity comparado com outras
heursticas
Esta fase inicia quando no h mais tarefas aguardando para executar e pelo me-
nos um processador est disponvel. Uma rplica pode ser criada para qualquer
tarefa em execuo. Contudo, ao contrrio de WQR, h um critrio e uma ordem
de prioridade para criao de rplicas. Considerando que o grau de replicao
de uma tarefa o nmero de rplicas criadas para esta tarefa, ento ao iniciar a
fase de replicao, os seguintes critrios so verificados na escolha de qual tarefa
deve ser replicada: i) a tarefa deve estar executando e ter um valor de afinidade
positivo, ou seja, alguma poro de sua entrada j deve estar presente no site de
algum dos processadores disponveis no momento; ii) o grau de replicao cor-
rente da tarefa deve ser o menor entre as tarefas que atendem o critrio (i); e iii)
a tarefa deve apresentar o maior valor de afinidade entre as tarefas que atendem
o critrio (ii).
Quando uma tarefa completa sua execuo as outras rplicas da tarefa so in-
terrompidas. O algoritmo finaliza quando todas as tarefas que esto executando
completam. At isto ocorrer, a replicao de tarefas continua.
Na Figura 13.16 apresentado uma comparao de desempenho entre trs heurs-

ticas: WQR, XSufferage e Storage Affinity. Esses resultados foram obtido atravs da
investigao de mais de 3.000 cenrios, onde vrios aspectos foram considerados
(i.e. heterogeneidade do Grid e da aplicao, tipo da aplicao e granularidade
da aplicao) [321]. possvel ver que Storage Affinity consegue melhor desem-

G UIA DE C LUSTER 13.3.4 - I MAGEM DO S ISTEMA
penho que heursticas que usam informao sobre o ambiente (XSufferage).
Um detalhe importante, mostrado na Figura 13.17 a grande diferena de des-

perdcio de recurso entre Storage Affinity e WQR. Esse efeito produzido devido
ao uso de estratgias de replicao diferentes pelas heursticas. O fato de WQR
no evitar transferncias reduz o desperdcio de CPU, por outro lado eleva bas-
tante o desperdcio de largura de banda da rede. Para Storage Affinity ocorre
exatamente o contrrio.
13.3.4 Imagem do Sistema
Ao usamos um computador, dependemos das abstraes criadas pelo sistema

operacional, tais como arquivos, diretrios, permisses e processos, para lidar-
mos com o sistema. So tais abstraes que nos permitem expressar o queremos
fazer. Elas tambm nos permitem nomear os dados persistentes que temos arma-
zenados no sistema. Atravs destas abstraes bsicas fornecidas pelo sistema
operacional, o usurio tem uma imagem do sistema, formada pelo conjunto de
objetos que ele pode manipular e pelas regras de manipulao destes objetos.
Plataformas de execuo de aplicaes paralelas que tem uma nica instncia

do sistema operacional (SMPs) automaticamente fornecem a seus usurios uma
imagem nica do sistema. J em plataformas que contm vrias instncias do
sistema operacional (MPPs, NOWs e Grids), necessrio construir uma imagem
consistente do sistema. Uma imagem consistente do sistema cria a iluso (ainda
que imperfeita) que os objetos que o usurio pode manipular so acessveis da
mesma forma de qualquer processador que compe a plataforma.
MPPs e NOWs contam com boa conectividade e administrao centralizada. Isso

permite a configurao dos processadores que compem a plataforma para com-
partilhar o mesmo cadastro de usurios e os sistemas de arquivo mais importante
(o /home, por exemplo), criando assim uma imagem razoavelmente consistente
do sistema. Grids, por outro lado, so amplamente dispersos e muitas vezes
sob controle de diversas entidades administrativas distintas. No factvel, por
exemplo, simplesmente montar o mesmo /home em todos os processadores que
compem o Grid, pois, alm de problemas de desempenho, h tambm questes
administrativas. Por outro lado, no queremos deixar que o usurio tenha que

G UIA DE C LUSTER 13.3.5 - S EGURANA
lidar com vrias imagens totalmente distintas do sistema.
As solues para este problema dividem-se em dois grandes grupos, aquelas que
evitam os problemas administrativos trabalhando nvel de usurio [258, 370] e
aquelas que introduzem novas abstraes para que o usurio possa lidar com o
Grid [120, 119]. Em princpio, solues nvel de usurio so mais simples de
usar pois suportam abstraes j conhecidas pelo usurio (e.g. arquivos). Entre-
tanto, elas podem apresentar srios problemas de performance dependendo da
aplicao e da conectividade do Grid. Novas abstraes, ao contrrio, requerem
o aprendizado de novos conceitos, mas podem vir a oferecer uma forma mais
eficiente de usar o Grid.
13.3.5 Segurana
Um dos desafios impostos pela introduo de um servio de execuo remota

(ver Seo 13.3.2) em um Grid relacionado a segurana. Ou seja, os problemas
de segurana podem afetar no apenas o proprietrio do recurso, como tambm
o usurio da aplicao. Ou seja, o recurso estar exposto ao permitir a execuo
de uma aplicao de um usurio de origem, a princpio, desconhecida. Por outro
lado, o usurio no gostaria que sua aplicao fosse sabotada durante a execuo
gerando resultados no confiveis.
Portanto, segurana um tpico que deve se considerado para o desenvolvi-

mento dos Grids Computacionais. Nesta seo iremos abordar algumas questes
de segurana que surgem ao se pensar em uma infraestrutura de computao na
escala de um Grid Computacional.
Proteo dos recursos
Uma vez que o Grid formado por vrios domnios administrativos distintos,
naturalmente possvel que a execuo de uma aplicao seja iniciada de uma
domnio X e utilize recursos dos domnios Y e Z. Porm, como saber se a apli-
cao iniciada por um usurio do domnio X no contm cdigo malicioso que
podem prejudicar o funcionamento dos recursos utilizados?

Uma primeira, e bvia, medida implementar mecanismos de autenticao e

autorizao para permitir que apenas usurios do domnio X, que sejam auten-
ticados pelos outros domnios, possam acessar os recursos autorizados por estes
domnios. Ainda assim, no se pode garantir que a credencial de acesso do usurio
no est sendo usada de forma incorreta, seja por corrupo (e.g. uso da m-
quina para disparar ataques de interrupo de servio) ou acidentalmente (e.g.
uma falha na aplicao pode criar uma vulnerabilidade) [29].
justamente por no ter garantias a esse respeito que mecanismos de proteo

para os recursos tm sido desenvolvidos. A idia bsica criar um ambiente
isolado, que no caso de ser comprometido no prejudique o funcionamento do
recurso. Uma abordagem comum a utilizao de virtualizao [241, 326, 81].
Uma das abordagens implementada pelo Jail [241, 326], que surgiu para prover
maior flexibilidade no gerenciamento de sistemas FreeBSD. A idia que o es-
quema de autorizao clssico do Unix pouco sofisticado para situaes onde
h uma demanda por uma granularidade mais fina nos nveis de permisses so-
bre o recursos. Essa estratgia funciona atravs do confinamento de um processo
e seus descendentes em uma rea (i.e. jail), nesta rea o processo s pode acessar
outros processos, sistemas de arquivo e recursos de rede que se encontram na
mesma partio.
Uma partio criada atravs da invocao chamada de sistema jail(). Alm

disso, o escopo do sistema de arquivos visvel pelo processo confinado utili-
zando a chamada de sistema chroot(). Esta chamada foi modificada para corrigir
vulnerabilidades que no permitiam a reduo da visibilidade do processo com
relao aos sistema de arquivos [241].
Note que no estamos tratando de partio necessariamente no que se refere ao

sistema de arquivos. A partio (ou jail) na qual o processo dever estar con-
finado composta de um ambiente com sistema de arquivos, processos e rede
isolados de outros processos.
Uma das vantagens do Jail que um usurio pode interagir com o recurso, en-
quanto algum processo remoto executa em uma partio isolada do resto do sis-
tema. Porm, isso pode causar inconvenientes para o usurio interativo, que na
maioria dos casos no est disposto a contribuir com seu recurso para o Grid,
caso isso implique em um consumo exagerado do recurso por parte do processo

estrangeiro. Sendo assim, outras alternativas fornecem mecanismos de deteco de

ociosidade que prepara o ambiente para receber processos estrangeiros e execut-
los em uma partio independente. Assim, espera-se que o usurio local no seja
prejudicado por um processo que, por exemplo, consume muita memria, uma
vez que o recurso estaria ocioso.
Outras solues tm o objetivo de no apenas garantir que o sistema estar a

salvo de qualquer tentativa de danificao, como de incio de ataques a partir
do recurso, como proteger o usurio de inconvenientes causados por aplicaes
que utilizam muito da capacidade do recurso. Pensando nisso, o Swan uma
soluo de sandboxing baseado na mquina virtual Xen [81]. O Swan dividido
em dois mdulos: i) Mode Switcher; ii) Virtual Machine.
O primeiro mdulo responsvel por monitorar o recurso, no intuito de detectar

sua ociosidade. Ao detectar a ociosidade o recurso muda do sistema operacional
no qual o usurio normalmente trabalha, para um sistema operacional modifi-
cado que garante o isolamento da aplicao remota do resto do sistema local.
Isso inclui um sistema de arquivos completamente diferente (i.e. uma partio
do disco diferente), a impossibilidade de enviar sinais para processos fora da m-
quina virtual e a restrio no acesso aos recursos de rede da mquina na qual est
executando. A vantagem dessa abordagem a explorao de ociosidade, porm
h o overhead gerado pela reinicializao em outro sistema operacional.
No estado atual, no encontramos um padro definido pelos comits da rea de

Grid Computing, porm vrios projetos apresentam solues semelhantes para a
proteo de recursos que formam o Grid.
Proteo da aplicao
Um outro lado da questo da segurana a proteo da aplicao que executa no

Grid. Ou seja, garantir que no haver sabotagem na execuo do servio requisi-
tado por um cliente. Por exemplo, suponha um servio que fornece renderizao
de imagens. O servio supostamente estaria disponvel para responder a requisi-
es de renderizao de clientes espalhados por vrios domnios administrativos.
Porm, por algum motivo, esse servio prioriza as requisies dos clientes locais
e retorna sempre a mesma imagem para qualquer requisio de clientes exter-

nos. Com isso o provedor do servio pretende economizar recursos que seriam
destinados computaes estrangeiras.
Certamente, essa uma situao simples de contornar, porm ainda assim pode
causar prejuzos para o usurio da aplicao cliente que requisitou a renderizao
da imagem. Portanto, necessrio munir o cliente de mecanismos e estratgias
de proteo contra este tipo de sabotagem.
Vrias estratgias de tolerncia sabotagem j foram propostas para ambientes

de computao voluntria, onde essa prtica parece ter um maior impacto, j
que os voluntrios, em geral, no so confiveis [324]. Um caso clssico foi o do
Seti@home, onde o que motivava a sabotagem era apenas o aspecto fama [59].
Voluntrios que mais fornecessem o servio de execuo para estas infraestrutu-
ras figuravam em um ranking. Assim, atravs de uma modificao no servio
de execuo, se tornava possvel enganar o sistema retornando um resultado in-
vlido que era contabilizado como trabalho til e melhorava a posio daquele
voluntrio no ranking.
Assim, uma estratgia simples usar o que se chama de majority voting [324],
que replica a execuo de uma unidade de trabalho entre vrios voluntrios do
sistema e espera at que um nmero m de resultados finais coincidentes sejam
retornados. Porm, esse esquema tem suas limitaes. Por exemplo, suponha
um ambiente com um nmero grande de voluntrios que retornam resultados
invlidos. A replicao crescer bastante em funo deste nmero para tolerar
essa quantidade de falhas. Isso, portanto, acarretar um nvel alto de desperdcio
de recursos.
Apesar da estratgia majority voting ter a vantagem de ser bastante simples de

implementar, ela no tolera situaes onde o nmero de resultados invlidos
muito alto. Desta forma, outras abordagens so propostas. Uma forma de contor-
nar a limitao do majority voting usar a poltica denominada spot-checking [324].
Nesse esquema, os voluntrios so verificados de forma aleatria atravs da soli-
citao de execuo de um benchmark. A inteno verificar se possvel confiar
nos resultados gerados por este voluntrio. Caso o benchmark detecte alguma
falha na computao efetuada, ou seja, os resultados retornados pelo voluntrio
no conferem com o resultado esperado do teste, os resultados anteriores retorna-
dos por este voluntrio so descartados e colocados na lista de trabalho pendente.

G UIA DE C LUSTER 13.4 - E STUDOS DE C ASO
Uma vez que spot-checking baseada na verificao aleatria da confiabilidade

dos voluntrios. Assim, ao detectar que um voluntrio no confivel, todos
os resultados anteriores deste voluntrio so descartados e o trabalho reenvi-
ado a outros voluntrios. Nesse estratgia, h uma menor repetio de traba-
lho, quando comparamos estratgia majority voting. Existem duas variaes da
estratgia spot-checking: i) spot-checking with blacklist; ii) spot-checking without blac-
klist. A diferena entre as duas o uso de uma lista com os voluntrios maliciosos.
Essa lista indica os voluntrios que no devem ser mais considerados. Para uma
maior discusso sobre as diferenas e implicaes de cada abordagem sugerimos
ao leitor o trabalho de Sarmenta et al. [324].
Devido ao fato de nem sempre ser possvel manter uma lista de voluntrios ma-
liciosos de forma eficiente. Por exemplo, usar o IP para identificar unicamente os
voluntrios maliciosos pode no ser uma boa idia, pois bastante comum o fato
dos hosts obterem IP dinmicos todas as vezes que se conectam. Sendo assim,
para resolver essa limitao surge uma nova abordagem baseada na definio de
credibilidade [324]. A idia marcar vrios objetos do sistema com um valor que
descreve sua credibilidade. Ento, possvel que voluntrios, resultados e gru-
pos de resultados tenham valores de credibilidade dependendo de vrios fatores.
Por exemplo, novos voluntrios que entram no sistema tm menos credibilidade
que antigos voluntrios, onde seus resultados passaram com sucesso por vrios
spot-checking. Naturalmente, a credibilidade dos resultados do voluntrio ter
bastante relao com sua prpria credibilidade, que pode evoluir ao passo que
sua computao vai sendo verificada. Note que uma combinao de majority vo-
ting e spot-checking uma alternativa possvel para determinao da credibilidade
dos voluntrios.
13.4 Estudos de Caso
13.4.1 Globus
Globus consiste de um conjunto de servios que facilitam a construo de infraes-

truturas para Computao em Grid [181]. Os servios Globus podem ser usados
para submisso e controle de aplicaes, descoberta de recursos, movimentao
de dados e segurana no Grid.

G UIA DE C LUSTER 13.4.1 - G LOBUS
Apesar desses servios fornecerem uma parte importante para a construo de

Grids Computacionais, existem outros servios alm desse ncleo. Estes servios,
igualmente importantes, podem ser construdos sobre essas camadas definidas
como a base de servios para a infraestrutura. Discutiremos nas sees seguintes
os aspectos mais importantes dessa infraestrutura de servios.
Autenticao
Um aspecto que complica o uso de Grids na prtica a autenticao de usurios

em diferentes domnios administrativos. Em princpio, o usurio tem que ser
autenticado para cada domnio administrativo de uma forma determinada pelo
administrador do domnio (que tipicamente envolve fornecer uma identificao
de usurio e uma senha). Este esquema coloca uma grande carga no usurio
(quem usa vrios sites Web que exigem login, tem uma idia bem concreta destes
problemas).
No contexto de Computao em Grid, os problemas causados pela mltipla au-

tenticao so agravados, pois queremos servios que possam efetuar aes auto-
maticamente, porm essas aes exigem autenticao (e.g. submeter uma tarefa
para execuo em um site remoto, solicitar o armazenamento ou acesso a um de-
terminado arquivo). Alm disso, como o objetivo do Globus permitir a criao
de organizaes virtuais, atravs da agregao de recursos e servios distribudos
por vrios domnios administrativos diferentes, certamente questes relaciona-
das a delegao de credencial esto envolvidas no processo de autenticao.
GSI (Globus Security Infrastructure) o servio Globus que ataca estes pro-
blemas. GSI viabiliza o login nico no Grid. GSI utiliza criptografia de chave
pblica, certificados X.509 e comunicao SSL (Secure Sockets Layer) para esta-
belecer a identidade Globus do usurio. Por exemplo, C=US,O=University
of California San Diego, OU=Grid Computing Lab, CN=Walfredo
Cirne era uma identidade em Gusto (o primeiro Grid montado com Glo-
bus). Depois do usurio ter se identificado junto ao GSI, todos os demais
servios Globus sabero, de forma segura, que o usurio de fato quem diz
ser. Uma vez que um servio sabe a identidade Globus do usurio, resta
estabelecer quais operaes tal usurio pode realizar. Isto feito mapeando a
identidade Globus para um usurio local. Por exemplo, o servio GRAM (veja

Seo 13.4.1) instalado em thing1.ucsd.edu mapeava C=US, O=University

of California San Diego, OU=Grid Computing Lab,CN=Walfredo
Cirne para walfredo. J o GRAM que executava em bluehorizon.sdsc.edu
mapeava C=US, O=University of California San Diego, OU=Grid
Computing Lab, CN=Walfredo Cirne para u15595.
Com a introduo da especificao OGSI, a partir do Globus 3.0, novas questes

de segurana tiveram que ser abordadas, principalmente pela convergncia com
Web Services. Ainda assim, vrios padres e especificaes que definem formatos
para descrio de polticas de segurana, formatos para delegao de credencial
e autenticao e estabelecimento de comunicao segura, puderam ser aprovei-
tados no intuito de prover uma infraestrutura de segurana para computao em
Grids baseada em componentes interoperveis [383].
O objetivo principal do conjunto de servios de segurana Globus, ilustrado na

Figura 13.21 como a camada GT3 Security Services, prover transparncia para os
servios das camadas de mais alto nvel com relao infraestrutura de segurana
do Grid.
Descoberta e Alocao de Recursos
Como discutimos na Seo 13.3.3, Grids no tm um escalonador que controla

todo o sistema. Assim sendo, quando um usurio submete uma aplicao para
execuo no Grid, o usurio utiliza um escalonador de aplicao que escolhe os
recursos a utilizar, particiona o trabalho entre tais recursos, e envia tarefas para
os escalonadores dos recursos, como ilustrado pela Figura 13.11.
GRAM (Globus Resource Allocation Manager) o servio da arquitetura Globus que

fornece uma interface uniforme para submisso e controle de tarefas [133], escon-
dendo a multiplicidade de escalonadores de recursos dos demais servios de Grid
(do escalonador de aplicaes, por exemplo). Alm disso, GRAM prov informa-
es sobre o status do recurso ao MDS (o servio Globus que fornece informao
sobre o Grid).
A Figura 13.18 permite um exame da arquitetura do GRAM, que esclarece bastante

sobre seus objetivos e funcionamento, atravs da identificao dos trs compo-

Figura 13.18: Arquitetura do GRAM [133]
nentes do GRAM (Gatekeeper, Job Manager e GRAM Reporter), bem como componen-
tes externos que interagem com o GRAM. O cliente GRAM aquele que o utiliza
para submeter e controlar a execuo de tarefas. Note que o cliente GRAM pode
ser um escalonador de aplicao ou at o prprio usurio. Para o cliente, a grande
vantagem de usar GRAM a manipulao uniforme de tarefas, i.e. a submisso
e controle de tarefas no importando qual o escalonador de recurso (Local Re-
source Manager, na Figura 13.18) usado para controlar a mquina. Isto possvel
porque as requisies enviadas ao GRAM so sempre escritas em RSL (Resource
Specification Language), independentemente de qual escalonador de recurso esteja
sendo utilizado. O Job Manager o responsvel por converter a requisio em
RSL em um formato que o escalonador de recurso em questo entenda. Ao que
sabemos, h verses do Job Manager para Condor [258], LoadLeveler [242], PBS,
Unix e Windows, entre outras plataformas.
Uma idia bastante interessante em Globus que escalonadores de aplicao po-

dem usar os servios de outros escalonadores de aplicao. O escalonador que
recebe a solicitao do cliente lida com a especificao em mais alto nvel. Ele
refina tal especificao e, para implement-la, submete novas solicitaes a esca-
lonadores de recurso (que de fato executam solicitaes) e/ou escalonadores de
aplicao (que utilizam outros escalonadores para executar solicitaes).
Globus suporta bem esta hierarquia de escalonadores atravs da linguagem RSL.

RSL capaz de expressar tanto solicitao de alto nvel (como a que o usurio
envia a seu escalonador de aplicaes), como tambm solicitaes concretas (que

so enviadas para GRAMs, que as traduzem para escalonadores de recurso locais).

Portanto, o trabalho de um escalonador de aplicao em Globus pode ser descrito
como sendo o de refinar solicitaes RSL. A Figura 13.19 ilustra este processo
no Globus 2.0. Note que Globus usa o termo broker para o que chamamos de
escalonador de aplicao.
Figura 13.19: Delegao entre escalonadores de aplicao [133]
Um componente importante para a execuo de aplicaes fortemente acopla-

das o co-alocador (Co-allocator). O co-alocador um escalonador de aplicao
especializado em garantir que tarefas localizadas em mquinas distintas execu-
tem simultaneamente. Em aplicaes fortemente acopladas, as tarefas precisam
se comunicar para que a aplicao faa progresso. Portanto, todas as tarefas da
aplicao tm que ser executadas simultaneamente. importante ressaltar que
uma boa implementao de co-alocao depende da implementao, por parte
dos escalonadores de recurso, do servio de reservas prvias (advance reservation).
Reservas prvias permitem a escalonadores de aplicao obter garantias de es-
calonadores de recurso que determinados recursos (e.g. processadores) estaro
disponveis para aplicao em um intervalo de tempo preestabelecido [340].
A Figura 13.20 apresenta um exemplo da submisso de uma aplicao em um

Grid Globus. Veja que um usurio envia uma solicitao de executar uma simu-
lao interativa envolvendo 100.000 entidades para um escalonador de aplicao
especializado em simulao interativa distribuda. Tal escalonador converte a so-

Figura 13.20: Exemplo do uso de escalonadores no Globus [133]
licitao original em outra mais especifica, que descreve a necessidade do usurio

em termos de ciclos, memria e latncia de comunicao. Esta nova solicitao
ento enviada a um escalonador de aplicao especializado em MPPs. Este es-
calonador consulta o MDS para descobrir quais MPPs (dentro aqueles aos quais
o usurio tem acesso) so os melhores para utilizar no momento. Alm disso,
o escalonador especializado em MPPs faz a partio do trabalho entre os MPPs
escolhidos e envia a solicitao mais refinada para o co-alocador. O co-alocador
garante que as tarefas submetidas aos distintos MPPs comecem a executar simul-
taneamente. Note tambm que outros escalonadores de aplicaes podem parti-
cipar do sistema. A Figura 13.20, por exemplo, exemplifica ainda escalonadores
para varredura de parmetros e para ambientes de colaborao virtual.
Comunicao
O problema de comunicao no Grid pode ser visto como uma instncia do eterno
conflito entre generalidade e performance. Caso utilizemos um mecanismo de
comunicao genrico (e.g. TCP) que viabilize a comunicao fim-a-fim entre
quaisquer duas tarefas no Grid, perdemos performance em casos especiais (e.g.

se ambas tarefas rodam em uma mquina de memria compartilhada, elas po-

deriam se comunicar muito mais rapidamente pela memria). Por outro lado,
gostaramos de usar um mecanismo genrico para no ter que programar para
cada uma das vrias tecnologias de comunicao existentes.
Globus ataca este problema com o Nexus [185]. Nexus fornece uma interface de
baixo nvel, mas uma implementao adaptvel que escolhe, dentre as tecnolo-
gias de comunicao disponveis, a que vai oferecer melhor performance. Por
exemplo, se ambas tarefas esto em uma mquina de memria compartilhada,
Nexus utilizar a memria para efetuar a comunicao. Caso as tarefas este-
jam em um MPP, Nexus utilizar o switch de alta velocidade para comunicao.
Caso as tarefas estejam em mquinas geograficamente distantes, Nexus utilizar
TCP/IP.
Nexus fornece uma interface de relativo baixo nvel: invocao remota de proce-
dimento, mas sem retorno de resultado. Portanto, programar diretamente em Ne-
xus no das tarefas mais agradveis. Entretanto, a idia da equipe Globus que
Nexus seja usado por desenvolvedores de ferramentas e mecanismos de comu-
nicao, no diretamente pelo desenvolvedor de aplicaes. MPI-G o exemplo
perfeito desta abordagem. MPI-G implementa o popular padro MPI (Message
Passing Interface) sobre Nexus. Assim, o desenvolvedor de aplicaes escrever
em MPI e link-editar sua aplicao com MPI-G para automaticamente ter acesso
a melhor tecnologia de comunicao disponvel (selecionada pelo Nexus).
Transferncia de Dados
A necessidade de acesso remoto e transferncia de dados uma constante na

Computao em Grid. Na verdade, vrias das aplicaes aptas a executar no Grid
necessitam de paralelismo exatamente porque processam enormes quantidades
de dados. Ciente deste fato, Globus logo disponibilizou GASS (Global Access to
Secondary Storage) [92], um servio para acesso remoto a arquivos sob a tutela
de um servidor GASS. O cliente GASS uma biblioteca C que link-editada
aplicao usuria do servio. Com o intuito de fornecer boa performance, o ser-
vio GASS implementa as otimizaes tpicas de acesso remoto como caching e
pre-fetching.

Apesar de ser um bom servio, o GASS encontrou problemas de implantao. A

dificuldade encontrada foi de interoperabilidade. A maioria das fontes de dados
onde se instalaria um servidor GASS j executa algum servio de transferncia
e/ou acesso remoto a arquivos. Os administradores de sistema se questionavam
ento porque no se poderia usar os servios existentes. Essa realidade moti-
vou a introduo do GridFTP [51] por parte da equipe Globus. GridFTP estende
o popular protocolo FTP para torn-lo mais adequado para as necessidades da
Computao em Grid. Mais precisamente, GridFTP introduz suporte a:
Autenticao GSI e Kerberos
Transferncia em paralelo (vrias conexes TCP entre fonte e destino)
Transferncia striped (conexes TCP entre vrias fontes e um destino, ou

vice-versa)
Controle manual dos buffers TCP (usado para afinamento de performance)
Instrumentao embutida
Uma vez que GridFTP uma extenso do FTP, o problema de interoperabilidade

fica resolvido, pois FTP amplamente suportado pelos servidores de dados. Ob-
viamente, se as extenses GridFTP no estiverem implementadas em um dado
servidor, os benefcios adicionais do protocolo no estaro disponvel. Mas o cli-
ente GridFTP ainda ser capaz de obter os dados desejados. Ou seja, o sistema
ser penalizado apenas no desempenho, porm continuar funcionando.
Avaliao do Globus
Um aspecto importante para grande aceitao do Globus que os servios ofe-

recidos so razoavelmente independentes, possibilitando que se utilize apenas
parte dos servios Globus em uma dada soluo. Essa possibilidade do uso par-
cial de Globus ajuda sobremaneira na adaptao de aplicaes paralelas existen-
tes para o Grid. Pode-se comear usando servios mais bsicos e ir, aos poucos,
incorporando funcionalidades mais avanadas. O design oposto abordagem
conjunto de servios independentes do Globus exemplificado pelo Legion [204].
Legion fornece um modelo orientado a objetos poderoso e flexvel. Entretanto, o

usurio tem que utilizar a soluo Legion de forma integral, sem estgios inter-
medirios. Esta diferena de abordagem talvez tenha contribudo para prevaln-
cia do Globus como padro de facto de infraestrutura para Computao em Grid.
interessante notar que a deciso de estruturar Globus como um conjunto de
servios independentes deixa claro que Globus no uma soluo pronta e com-
pleta (plug-and-play) para construo de Grids. Globus certamente fornece servi-
os teis para Computao em Grids. Mas, desenvolvedores, administradores e
usurios precisam despender certo esforo para finalizar seu Grid. Por exemplo,
administradores precisam decidir quais usurios tero acesso a quais recursos
que compem o Grid e em quais condies este acesso se dar (veja Seo 13.4.1).
Em outro exemplo, freqentemente necessrio desenvolver escalonadores de
aplicao (veja Seo 13.3.3) que tenham conhecimento sobre as aplicaes que
sero executadas e algumas vezes tambm sobre a estrutura do Grid a ser usado.
Computao em Grid simplesmente muito complexa para possibilitar solues

plug-and-play. Portanto, o fato do Globus no ser uma soluo pronta e completa
no nenhum demrito. Entretanto, algumas pessoas tm a idia de que Globus
a soluo, completa e perfeita. Esta falsa concepo, sim, um problema pois gera
falsas expectativas e obscurece discusses tcnicas com alegaes de marketing.
Vale ressaltar que a discusso apresentada nas sees anteriores vlida para o
Globus 2.0. Ainda se torna pertinente apresentar as caractersticas do Globus 2.0,
pois muitos grupos interessados em computao de alto desempenho utilizam
infraestruturas baseadas no GT2 (Globus Toolkit 2.0).
A introduo do padro OGSA criou um alinhamento com tecnologias e padres

Web Services, assim vrios desses aspectos discutidos anteriormente se modifica-
ram em busca da implementaes de padres que promovem maior interopera-
bilidade.
A arquitetura do Globus Toolkit 3 ilustrada pela Figura 13.21. Essa verso uma
implementao da especificao OGSI (Open Grid Services Infrastructure) [368], os
servios implementados na camada GT3 Core Services representam os servios
especificados pela OGSI. O objetivo especificar mecanismos para criao, geren-
ciamento e troca de dados entre Grid Services.
Como discutimos nas Sees 13.2.7 e 13.2.7, h uma tendncia forte de conver-
gncia entre as tecnologias de Grids Computacionais e Web Services. Isso fica

G UIA DE C LUSTER 13.4.2 - M Y G RID
Figura 13.21: Arquitetura do Globus [345]
claro com a introduo da especificao WSRF, que posiciona as tecnologias de

Grids junto aos padres para Web Services.
13.4.2 MyGrid
A motivao para a construo do MyGrid surgiu do fato que, embora bastante

pesquisa tenha sido realizada para o desenvolvimento dos Grids Computacio-
nais, poucos usurios executavam suas aplicaes paralelas sobre essa infraes-
trutura. Assim, foi concebido projeto MyGrid, com o intuito de alterar esta situa-
o. Para tanto, foram atacadas apenas aplicaes Bag-of-Tasks, ou seja, aquelas
aplicaes cujas tarefas so independentes, podendo ser executadas em qualquer
ordem. Aplicaes Bag-of-Tasks so um alvo interessante porque (i) se adequam
melhor a ampla distribuio, heterogeneidade e dinamicidade do Grid, e (ii) re-
solvem vrios problemas importantes, tais como minerao de dados, processa-
mento genmico, pesquisa massiva (como quebra de chaves criptogrficas), var-
redura de parmetros, simulaes Monte Carlo (muito utilizado, por exemplo,
pela indstria farmacutica [215]), computao de fractais (como Mandelbrot), e
manipulao de imagem (como tomografia).
Estabelecido o escopo do MyGrid, nosso objetivo construir um sistema simples,

completo e seguro. Por simples queremos dizer que o esforo para utilizao do
MyGrid deve ser mnimo. Em particular, queremos chegar o mais prximo pos-
svel de uma soluo pronta (plug-and-play). Por completo denotamos a neces-
sidade de cobrir todo o ciclo de uso de um sistema computacional, do desenvol-
vimento execuo, passando por instalao e atualizao e incluindo tambm

a manipulao de arquivos. Por seguro expressamos a necessidade de no in-

troduzir vulnerabilidades ao ambiente computacional do usurio. Ou seja, no
queremos que falhas de segurana em qualquer uma das mquinas que o usurio
possa utilizar sejam propagadas para sua mquina base (i.e. o computador usado
pelo usurio).
MyGrid diferencia entre mquina base e mquina do Grid. Em um MyGrid, a

mquina base aquela que controla a execuo da aplicao. Ela tipicamente
contm os dados de entrada e coleta os resultados da computao. A mquina
base normalmente usada pelo usurio diretamente no seu dia-a-dia, muitas ve-
zes sendo o prprio computador desktop do usurio. Esperamos, portanto, que
o usurio tenha excelente acesso mquina base e que tenha customizado um
ambiente de trabalho confortvel nela.
Todas as mquinas usadas via MyGrid para executar tarefas so chamadas de

mquinas de grid. Ao contrrio da mquina base, no assumimos que o usurio
customizou cada mquina do Grid para criar-lhe um ambiente de trabalho fami-
liar. Alm disso, todas as mquinas do Grid tipicamente no compartilham um
mesmo sistema de arquivo ou tm os mesmos softwares instalados. A imagem
do sistema pode variar de uma mquina do Grid para outra. Portanto, para man-
termos a simplicidade de uso do sistema, precisamos evitar que o usurio tenha
que lidar diretamente com as mquinas do Grid. Por exemplo, queremos evitar
que o usurio tenha que instalar software em cada mquina de seu Grid. A idia
que mquinas do Grid sejam manipuladas atravs das abstraes criadas por
MyGrid (descritas a seguir).
Um aspecto importante de MyGrid dar ao usurio a possibilidade de usar quais-

quer recursos que ele tenha acesso . Este no um objetivo trivial porque ele im-
plica que temos que assumir muito pouco a respeito de uma mquina do Grid, de
forma a no impedir algum usurio de usar uma mquina que no suporta nos-
sas hipteses. Em particular, no podemos assumir que tal recurso tenha software
MyGrid instalado. MyGrid define Grid Machine Interface como sendo o conjunto
mnimo de servios que precisam estar disponveis para que uma dada mquina
possa ser adicionada ao Grid do usurio. Tais servios so:
Como ilustrado pela Figura 13.22, h vrias formas de implementar os servios

oferecidos atravs da Grid Machine Interface. Uma forma fornecer ao sistema
scripts que implementam os servios listados na Tabela 13.2. Neste caso, MyGrid

Servios
Execuo remota
Transferncia de Arquivo (Mquina Base 7 Grid Machine)
Transferncia de Arquivo (Grid Machine 7 Mquina Base)
Interrupo de uma Execuo mltipla
Tabela 13.2: Grid Machine Interface
Figura 13.22: Arquitetura do MyGrid
utiliza o mdulo Grid Script para acessar a m-quina em questo. Note que Grid
Script possibilita que, qualquer que seja a mquina que o usurio tem acesso, ele
possa informar como este acesso se d atravs da escrita de trs scripts. Alter-
nativamente, h casos em que a forma de acessar uma determinada mquina do
Grid j do conhecimento do MyGrid. Por exemplo, suponha que a mquina
em questo pode ser acessada via servios Globus (GSI, GRAM e GridFTP). Neste
caso, o usurio no precisa fornecer os scripts, indicando apenas que o acesso
mquina j conhecido de MyGrid. Finalmente, MyGrid tambm prov um me-
canismo de acesso a mquinas do Grid, chamado de User Agent. O User Agent
prov servios simples. interessante notar que, pela terminologia adotada por
Foster, et al. [184], Grid Machine Interface umavirtualizao para os servios de
acesso a uma mquina do Grid.
Outro componente fundamental a arquitetura MyGrid o Scheduler. O Scheduler

recebe do usurio a descrio das tarefas a executar, escolhe qual processador
usar para cada tarefa, e finalmente submete e monitora a execuo da tarefa. O

MyGrid possui atualmente duas heurstica de escalonamento: Workqueue with

Replication (WQR) [299] e Storage Affinity [321]. Ambas, conseguem obter uma
boa performance mesmo sem utilizar informaes sobre o estado do Grid ou o
tamanho de cada tarefa (ver Seo 13.3.3 e Seo 13.3.3). O WQR foi definido
para aplicaes cpu-intensive, enquanto Storage Affinity foi desenvolvido para
melhorar o desempenho de aplicaes que processam grandes quantidades de
dados.
Note que ter um algoritmo de escalonamento que funciona bem sem depender
de muita informao importante, pois simplifica a definio da Grid Machine
Interface. Caso o algoritmo de escalonamento do MyGrid necessitasse de infor-
maes sobre as mquinas do Grid, Grid Machine Interface teria que ser mais rica
e, portanto, mais difcil de virtualizar. Por exemplo, o Nimrod-G [102] define uma
interface de abstrao para os recursos, que contempla mtodos de fornecimento
de informao sobre o recurso. Certamente, a informao obtida por esses m-
todos valiosa para o escalonamento eficiente das aplicaes. Porm, isso limita
o tipo de recurso que pode ser utilizado, pois torna o middleware dependente de
um recurso que fornea uma implementao para os mtodos dessa interface.
Uma aplicao (ou Job) MyGrid composta de tarefas independentes. Estas tare-
fas so compostas por trs partes ou sub-tarefas: init, remote e final. As sub-tarefas
so executadas seqencialmente (init 7 remote 7 f inal). As sub-tarefas init e
final so usadas para efetuar as transferncias de arquivo de entrada e sada da
tarefa respectivamente. Sendo assim, tanto a sub-tarefa inicial quando a final
so executadas na mquina base. Enquanto, a sub-tarefa remote, como o prprio
nome sugere, executada em uma mquina do Grid e realiza a computao pro-
priamente dita da tarefa.
Para definir as sub-tarefas inicial e final, o usurio tem disponvel algumas abs-
traes providas pelo MyGrid para lidar com a mquina do Grid sem necessitar
de conhecer sua imagem do sistema. As abstraes providas pelo MyGrid so
storage e playpen. O servio de storage possui a semntica de uma rea de ar-
mazenamento persistente execuo da tarefa. Ou seja, til usar storage para
distribuio de arquivos que provavelmente sero reutilizados no Grid (ex.: exe-
cutveis da aplicao). Assim sendo, qualquer arquivo transferido para o storage
automaticamente includo no PATH da mquina do Grid. Por outro lado, o
playpen prov uma rea de armazenamento temporria de maneira independente

G UIA DE C LUSTER 13.4.3 - O UR G RID
das convenes locais do sistema de arquivo de uma dada mquina do Grid. Essa
rea de armazenamento temporria criada automaticamente e o diretrio base
de execuo da sub-tarefa remote. Note que o playpen foi concebido para possibi-
litar o armazenamento de dados temporrios e resultados de tarefas. Tambm no
sentido de simplificar a escrita das sub-tarefas, as variveis de ambiente $ STO -
RAGE , $ PLAYPEN , $ PROC e $ TASK so automaticamente definidas pelo MyGrid
e contm, respectivamente, o caminho completo para rea de storage, o caminho
completo para o playpen de uma dada tarefa, o nome da mquina do Grid esco-
lhida para executar a tarefa e um identificador da tarefa.
13.4.3 OurGrid
Ao contrrio do Globus, a soluo OurGrid tem um escopo diferente, porm com-

plementar. O objetivo prover uma soluo efetiva para a execuo de aplicaes
Bag-of-Tasks em Grids Computacionais. Sendo assim, as decises de projeto es-
to centradas no uso da soluo em ambientes de produo. Portanto, a idia
bsica abdicar da generalidade, em alguns casos, no intuito de se obter uma so-
luo, apesar de simples, eficiente e que possa ser facilmente usada em produo.
A arquitetura do OurGrid, brevemente comentada na Seo 13.2.6 e ilustrada na

Figura 13.5, formada por trs componentes: MyGrid Broker (ver Seo 13.4.2),
OurGrid Peer e uma soluo de sandboxing baseada na mquina virtual Xen [81].
Nas sees seguintes descreveremos como os componentes do OurGrid abordam
alguns aspectos importantes da Computao em Grid.
Autenticao
Na arquitetura OurGrid existem basicamente dois nveis de autenticao. Esses

nveis dependem de como o usurio obteve o recurso. Primeiramente, o usurio
pode ter acesso direto a alguns recursos (i.e. Grid Machines - G U Ms - em sua rede
local), neste caso o usurio usa o esquema de autenticao tradicional, em geral,
isso implica na utilizao da infraestrutura de autenticao do sistema operacio-
nal do recurso, ou seja, nome de usurio (login) e uma senha.
Contudo, alm das G U Ms que o usurio tem acesso direto, OurGrid permite (e

promove) a obteno de acesso a G U Ms de outros sites, isso ocorre atravs de um

OurGrid Peer local ao site do usurio. Este peer deve estar conectado rede de
favores (ver Figura 13.5). Assim, para as G U Ms obtidas da comunidade, h uma
autenticao em duas vias baseada em certificados digitais no formato X.509. A
primeira parte da autenticao deve garantir que o usurio tem permisso para
solicitar servios s G U Ms (i.e. que a GuM conhece o usurio que est requi-
sitando seus servios). A segunda parte deve garantir que o usurio no est
solicitando servios a uma falsa G U M. Ou seja, tanto o usurio, atravs do bro-
ker, quanto os peers da comunidade possuem uma lista de certificados que so
usadas para validar a tentativa de aceso.
Isso impede que usurios no autorizados pelo peer, obtenham acesso aos servi-
os de descoberta de novas Grid Machines, transferncia de arquivos, execuo
e gerenciamento do ciclo de vida de replicas fornecido pelas G U Ms controladas
por um dado peer.
Outro aspecto importante que atravs da utilizao de certificados, a comunica-

o entre o MyGrid Broker, o peer e as Grid Machines ser segura, evitando que
os dados sejam interceptados e manipulados durante a comunicao. A segu-
rana na comunicao fornecida atravs do uso de RMI baseado em SSL (Secure
Socket Layer), que garante comunicao criptografada.
Descoberta e Alocao de Recursos
Para executar uma aplicao usando a OurGrid o usurio deve descrever sua
aplicao e o conjunto de recursos que o usurio tem acesso. Note que esse con-
junto de recursos pode ser apenas a indicao de um OurGrid Peer, que tem a
funo de obter recursos para o usurio.
A descrio da aplicao basicamente: um conjunto tarefas, seus arquivos de

entrada, arquivos de sada e seus requisitos (e.g. sistema operacional necess-
rio, mnimo de memria, arquitetura do processador). Em seguida, o usurio o
submete sua aplicao para execuo no Grid atravs do MyGrid Broker. O com-
ponente interno do MyGrid Broker que recebe a submisso o Scheduler. Por sua
vez, o Scheduler requisita aos provedores de G U Ms recursos para executar a apli-
cao submetida pelo usurio. Esses provedores podem responder com recursos

locais ou recursos obtidos na rede de favores. Para que o Scheduler receba uma
resposta dos provedores necessrio que tenha sido encontrada uma G U M que
preenche os requisitos determinados na descrio da aplicao.
Portanto, aps ter sido descoberto um recurso que possui atributos compatveis
com os requisitos da aplicao, o recurso alocado e repassado para o Scheduler
que o solicitou. Certamente, isso s ir ocorrer caso o recurso esteja disponvel.
Porm, caso o recurso tenha sido descoberto atravs da rede de favores, o recurso
pode ser tomado de volta (i.e. preemptado) pelo peer que o forneceu, seguindo
a dinmica da rede de favores. A preempo um evento natural e previsto
pela arquitetura do OurGrid, uma vez que os recursos s so cedidos caso esteja
ocioso. Ou seja, uma solicitao local no site, ao qual o recurso pertence, pode
ocasionar a preempo.
Vale tambm ressaltar que a alocao do recurso feita no nvel do MyGrid Bro-
ker, ou seja, isso no significa que o recurso estar dedicado exclusivamente ao
MyGrid Broker. Portanto, no h impedimento para que outras aplicaes que
no usam a infraestrutura do OurGrid estejam executando concorrentemente
com a aplicao submetida pelo usurio.
Comunicao
Uma vez que o foco da soluo OurGrid est nas aplicaes Bag-of-Tasks, no faz
parte do escopo da soluo OurGrid prover mecanismos de comunicao para
aplicaes fortemente acopladas. Mesmo assim, possvel usar a infraestrutura
OurGrid para executar aplicaes deste tipo, desde que a execuo seja interna a
um site. Por exemplo, uma aplicao que usa MPI, quando descrita pelo usurio,
pode ter especificado em seus requisitos que necessita de uma G U M (Grid Ma-
chine), que na verdade o front end de uma coleo de vrios processadores (i.e.
um cluster). Essa demanda ser atendida se existir uma GuM, no alocada, que
possua um atributo compatvel com o requisito especificado pela aplicao. Por-
tanto, apesar de no ter uma arquitetura que prov comunicao entre as tarefas
que esto sendo executadas nas GuMs, a soluo OurGrid prov meios de agre-
gar ao Grid GuMs que permitem a execuo de aplicaes fortemente acopladas.

Transferncia de Dados
A soluo OurGrid para transferncia de dados baseada no tratamento de ar-

quivos. Desta forma, o usurio ao descrever sua aplicao tem a sua disposio
o uso de trs operaes de transferncia arquivos, put, store e get, que podem
ser usadas para preparar o ambiente para execuo da aplicao (colocando os
arquivos nos sites onde a aplicao ir executar), como tambm coletar os dados
resultantes do processamento.
Tanto put quanto store so operaes que permitem a transferir arquivos para
a GuM. A diferena entre as duas operaes consiste apenas do fato que store
evita a transferncia do arquivo caso o arquivo j se encontre armazenado no
lado remoto. Isso til, por exemplo, para executveis da aplicao e dados que
so reutilizados entre execues sucessivas da aplicao. A terceira operao, get,
fornece um mtodo de coletar arquivos resultantes da execuo das aplicaes.
A infraestrutura de comunicao usada para a transferncia a mesma usada

para a solicitao de servios de execuo, ou seja, RMI. Uma vez que possvel
ter segurana na comunicao com as GuMs de RMI sobre SSL, as operaes de
transferncias de dados tambm gozam da segurana fornecida pela camada de
comunicao baseada em certificados.
Avaliao do OurGrid
A caracterstica mais importante do OurGrid conseguir prover uma soluo til

e eficiente para uma comunidade de usurios em produo, apesar de se basear
em solues simples e de escopo limitado (i.e. apenas aplicaes do tipo Bag-of-
Tasks).
importante notar que o objetivo do OurGrid contrasta com o objetivo do Glo-

bus, que fornece um conjunto de servios para a construo da infraestrutura do
Grid. Portanto, OurGrid uma soluo que complementa o Globus provendo
um broker (i.e. MyGrid) e abstraes que permitem o usurio usar recursos Glo-
bus e no-Globus. Por outro lado, Globus complementa o OurGrid ao fornecer a
infraestrutura de servios para execuo de aplicaes em larga escala.

G UIA DE C LUSTER 13.4.4 - C ONDOR
OurGrid persegue um objetivo diferente do que seria prover uma soluo ge-
nrica para computao em Grid. Com o foco em aplicaes BoT foi possvel
produzir uma soluo efetiva para uma comunidade de usurios em produo.
No se quer dizer com isso que no se pretende introduzir novas funcionalida-
des, que aumentem o escopo da soluo. Ao contrrio, a idia gradativamente
permitir que mais aplicaes possam utilizar a soluo. Por exemplo, suporte a
workflow, suporte a data-mining, etc.
Atualmente na verso 3.0.2, OurGrid j usado em produo por vrios grupos

de pesquisa no Brasil [117]. As prximas verses prometem incorporar melho-
rias no escalonamento de aplicaes, soluo de sandboxing, bem como maior
tolerncia para aplicaes de longa durao (high-throughput computing) atravs
do uso de checkpoint. O software OurGrid est disponvel para download em
http://www.ourgrid.org.
13.4.4 Condor
De forma semelhante ao OurGrid, Condor uma sistema que possui um escopo

bem definido e menos genrico que outras solues para computao de alto de-
sempenho em Grids Computacionais. Condor objetiva fornecer grande quanti-
dade de poder computacional a mdio e longo prazo (dias a semanas) utilizando
recursos ociosos na rede [258]. Os autores do sistema salientam insistentemente
que Condor objetiva alta vazo (high throughput) e no alto desempenho (high per-
formance) [85, 165, 191, 258]. Entenda-se disto que Condor visa fornecer desempe-
nho sustentvel a mdio e longo prazos, mesmo que o desempenho instantneo
do sistema possa variar consideravelmente.
Condor foi inicialmente concebido para funcionar em N O Ws (Network of Works-

tations). Uma N O W que executa Condor denomina-se Condor Pool. O elemento
arquitetural mais importante de um Condor Pool o Matchmaker. O Matchmaker
aloca tarefas a mquinas pertencentes ao Pool. Tal alocao baseada nas necessi-
dades de cada tarefa e nas restries de uso de cada mquina. As necessidades de
uma tarefa so especificadas pelo usurio quando de sua submisso. Por exem-
plo, uma tarefa pode precisar de uma mquina Sun Sparc, rodando Solaris, com
pelo menos 256M B de memria. J as restries de uso de uma dada mquina,
estas so especificadas por seu dono quando da incluso da mquina no Pool. Por

G UIA DE C LUSTER 13.4.4 - C ONDOR
exemplo, o dono pode preferir que sua mquina execute as aplicaes de Joo, se-
guido das aplicaes do grupo de sistemas operacionais, e que nunca execute as
aplicaes de Pedro. Ou seja, as restries permitem ao dono determinar como
sua mquina ser usada no Condor Pool. Tipicamente, o dono estabelece tam-
bm que sua mquina s usada quando estiver ociosa e que, quando ele voltar
a utilizar a mquina, qualquer aplicao Condor em execuo seja suspensa ime-
diatamente.
Um aspecto interessante do Condor que ambos usurios e donos de mquinas

so representados no sistema por agentes de software. O Customer Agent (Agente
do Usurio) envia as necessidades da tarefa para o Matchmaker. De forma simi-
lar, Resource Owner Agent envia as restries de uso do recurso ao Matchmaker.
Ao efetuar o casamento de padres entre tarefa os requisitos da tarefa e os atribu-
tos da mquina, o Matchmaker notifica ambos Agentes. A partir da, os Agentes
interagem diretamente para realizar a execuo da tarefa. A Figura 13.23 ilustra
este protocolo.
Figura 13.23: Condor protocol [85]
Outro aspecto atraente do Condor seu mecanismo de checkpointing. Uma vez

que o dono normalmente especifica que sua mquina seja desocupada pela tarefa
Condor assim que ele retornar a us-la, garantir progresso das tarefas torna-se um
problema no-trivial. Condor aborda esta questo fazendo o checkpoint da tarefa
(i.e. salvando transparentemente o estado de sua execuo). Isto permite que a
tarefa seja reexecutada em outra mquina a partir do ponto em que parou. Vale
salientar que o mecanismo de checkpoint do Condor implementado atravs da
substituio da biblioteca do sistema por uma biblioteca Condor.

G UIA DE C LUSTER 13.5 - I NTEGRAO DE CLUSTERS EM GRIDS
Condor foi posteriormente estendido para execuo em Grids [165, 191]. inte-
ressante notar que Condor dispe de duas formas de funcionamento em Grids:
Flock of Condors [165] e Condor-G [191].
Flock of Condors um trabalho que antecede Condor-G. Um Flock of Condors

um Grid formado por vrios Condor Pools [165]. A construo do Flock bas-
tante elegante do ponto de vista de sistemas distribudos pois no acrescenta ne-
nhuma centralizao a arquitetura Condor original. A base para criao de um
Flock um acordo de cooperao (de troca de recursos) entre dois Condors Po-
ols. Portanto, por maior que seja o Flock, suas ligaes so sempre dois-a-dois,
sem envolver nenhuma entidade centralizadora. Mais que isso, o Flock of Con-
dors no chega a alterar o software Condor original. Todo a funcionalidade do
Flock of Condors implementada por uma mquina especial, chamada Gateway.
Ambos os Pools que firmam um acordo de cooperao instalam cada qual um Ga-
teway. Os dois Gateways mantm comunicao constante para troca de tarefas
entre os Pools. Para o Pool local, o Gateway uma mquina qualquer. Entretanto,
ao invs de oferecer seus prprios recursos, o Gateway simplesmente representa
os recursos do Pool remoto, republicado as restries estabelecidas pelos donos
das mquinas remotas. Quando uma tarefa recebida pelo Gateway, este a re-
passa para o Gateway remoto que ento a encaminha para uma mquina do pool
remoto.
Talvez por ser mais recente, o Condor-G adota uma viso mais heterognea de
Grid. Alm de Condor Pools, Condor-G tambm utiliza recursos via Globus. De-
vido necessidade de suportar mais heterogeneidade, Condor-G usa uma arqui-
tetura mais centralizada que o Flock of Condors. O Condor-G Scheduler controla
a execuo da aplicao, submetendo tarefas tanto a Condor Pools quanto a recur-
sos acessveis via Globus (como MPPs). No caso de recursos Globus, Condor-G
utiliza os servios GRAM, GASS, MDS e GSI para viabilizar a execuo das tarefas.
13.5 Integrao de clusters em grids
Clusters so um tipo de recurso de especial interesse para usurios de grids, de-

vido enorme capacidade computacional que so capazes de fornecer. Porm, a
utilizao dos clusters no uma tarefa trivial, devido a caractersticas inerentes

G UIA DE C LUSTER 13.5 - I NTEGRAO DE CLUSTERS EM GRIDS
ao sistema.
Clusters (em especial os de alto desempenho) so comumente utilizados atravs

de gerenciadores de recursos. Estes gerenciadores controlam a fila de acesso,
os direitos de acessos dos usurios e coordenam o uso dos recursos, garantindo
que somente usurios autorizados acessem os recursos, na quantidade a que tm
direito e pelo tempo igualmente permitido.
Para um usurio ser capaz de especificar uma quantidade de mquinas e um

tempo de utilizao das mesmas, ele precisa conhecer a sua aplicao e a capa-
cidade das mquinas, a fim de estabelecer um tempo de utilizao razovel. Se
o tempo for subestimado, a aplicao no completar antes do usurio perder
o direito de acesso aos recursos, desperdiando a utilizao do recurso (pois o
uso de mecanismos de retomada de aplicaes parcialmente executadas no
difundido em todas as comunidades de usurios de aplicaes de alto desempe-
nho). Se o tempo for superestimado, o incio da execuo da aplicao tende a
ser postergado (por caractersticas dos algoritmos de escalonamento comumente
utilizados pelos gerenciadores, que tendem a encaixar requisies menores em
espaos de alocao que no so suficientes para atender as requisies maiores,
adiantando as primeiras).
Em grids, o problema da dificuldade de estabelecer o tempo de execuo au-

menta, pois possvel que o usurio sequer conhea a capacidade das mquinas
que ir receber.
Alm deste problema, existe um outro fator prejudicial utilizao de clusters em

grids, que o fato de diferentes gerenciadores de clusters possuirem diferentes
linguagens de requisies. Isto exige que exista um componente entre o grid e
o cluster (chamado de conector) capaz de prover uma linguagem nica sobre a
qual requisies do grid podem ser enviadas de forma padronizada, tendo este
componente a funo de converter estas requisies para a linguagem especfica
do gerenciador utilizado no determinado cluster (Figura 13.24).

G UIA DE C LUSTER 13.5.1 - G LOBUS GRAM
Figura 13.24: Utilizao de clusters em grids.
13.5.1 Globus GRAM
Um destes componentes capaz de converter requisies de grid para clusters es-

pecficos o GRAM (Grid Resource Allocation and Management) do Globus.
Ele recebe as requisies (RSL Resource Specification Language) e capaz de
convert-las para gerenciadores especficos.
No entanto, um GRAM capaz de atender um nico recurso. No contexto do

GRAM, um recurso pode ser um cluster gerenciado por um gerenciador de re-
cursos especfico, ou pode ser uma nica mquina ou um conjunto de mquinas
gerenciadas pelo Condor.
Se um determinado local contar com mais de um recurso, dever existir um

GRAM para controlar cada um.
13.5.2 Alocao transparente de recursos
Uma tcnica que pode ser empregada para evitar que usurios tenham que espe-
cificar o tempo e o nmero de mquinas que desejam utilizar, alm de ser menos
invasivo do ponto de vista da utilizao do cluster a tcnica de alocao trans-
parente, apresentada originalmente em [288].
A tcnica pode ser utilizada quando a aplicao a ser executada no grid com-
posta de tarefas independentes (como por exemplo aplicaes Bag-of -Tasks). Com
o seu uso, no necessrio que sejam alocadas mquinas para que usurios de
grid possam executar suas tarefas: todas as mquinas que no esto em uso por
usurios locais so disponibilizadas grade, e ficam disponveis para a execu-

G UIA DE C LUSTER 13.6 - T ENDNCIAS EM G RIDS C OMPUTACIONAIS
o de tarefas at que sejam requisitadas por usurios locais (isto , usurio que
possuem direito de acesso ao recurso), momento em que so retiradas da grade e
alocadas a tal usurio.
Como esta tcnica utilizada para a execuo de tarefas independentes, o cance-

lamento sbito da tarefa no causar falha na execuo da aplicao: ela apenas
ser atrasada, uma vez que a tarefa dever ser re-escalonada e re-executada desde
o seu incio. Se a aplicao (ou o grid) oferecer algum tipo de mecanismo de reto-
mada de execuo de tarefas (por exemplo, checkpointing), o tempo de atraso da
aplicao ser menor.
Dependendo do modelo de utilizao do cluster, esta tcnica pode apresentar me-

lhor tempo de execuo de tarefas de grade do que outras heursticas, ao mesmo
tempo em que se mostra menos invasiva ao cluster: usurios locais no deixaro
de utilizar estes recursos devido a presena de tarefas da grade, o que pode in-
centivar administradores de clusters a cederem o seu cluster (em especial, os seus
ciclos ociosos) para o grid.
A tcnica atualmente aplicada com sucesso para integrar clusters na comuni-

dade OurGrid.
Formas como tal heurstica pode ser implementada na prtica, avaliao da tc-
nica sobre alguns cenrios, mostrando o seu desempenho e outras consideraes
sobre a Alocao Transparente podem ser encontradas em [288].
13.6 Tendncias em Grids Computacionais
Neste captulo foi apresentando os principais aspectos dos Grids Computacio-

nais, desde a apresentao de um conceito do que classifica uma infraestrutura
de computao distribuda como um Grid Computacional, at o estado atual do
desenvolvimento de tecnologia para a construo dessas infraestruturas.
Vimos que Grids Computacionais levantam questes em vrias reas de pes-

quisa, porm seus benefcios vo alm de uma simples plataforma para execu-
o de aplicaes em larga escala. A idia facilitar a colaborao de grupos de

G UIA DE C LUSTER 13.6 - T ENDNCIAS EM G RIDS C OMPUTACIONAIS
pesquisa distribudos geograficamente.
Mostramos ento que os Grids Computacionais como uma tecnologia que nas-
ceu na comunidade de alto desempenho e ganhou espao na indstria atravs
da transformao da computao distribuda pelo uso de servios sob demanda.
Assim, a convergncia de tecnologias que culminou com a definio do conceito
de Grid Service foi um processo natural de evoluo dos Grids.
Tendo em vista a nova perspectiva que os Grid Services trouxeram para o de-
senvolvimento dos Grids, a tendncia que Grids se tornem uma infraestrutura
global de computao orientada a servios, atendendo tanto a comunidade de
computao cientfica de alto desempenho, quanto a comunidade de computa-
o comercial.
Finalmente, a discusso sobre os padres emergentes para o desenvolvimento de

infraestruturas de Grids Computacionais, mostra que os esforos tm amadure-
cido, fomentado a pesquisa e o desenvolvimento de ferramentas, que contribuem
para a concretizao de um ambiente amplamente distribudo onde ser possvel
consumir servios computacionais de forma transparente.

Captulo 14
Virtualizao de recursos
Virtualizao o modo de apresentao ou agrupamento de um subconjunto l-

gico de recursos computacionais de modo que possam ser alcanados resultados
e benefcios como se o sistema estivesse executando sobre a configurao nativa.
A virtualizao de recursos geralmente incluem o armazenamento de dados e
poder de processamento. Deste modo, a virtualizao dos recursos no restrita
somente a execuo, posio geogrfica ou pela configurao fsica de recursos.
Uma tendncia nova na virtualizao o conceito de um motor de virtualiza-

o" que d uma viso holstica de toda a infra-estrutura de rede usando a tcnica
de agregao. Um outro tipo popular de virtualizao e atualmente muito utili-
zado a virtualizao de hardware para rodar mais de um sistema operacional ao
mesmo tempo, atravs de microkernels ou de camadas de abstrao de hardware,
como por exemplo o XEN.
14.1 Principais tipos de virtualizao
Virtualizao um termo muito amplo que leva abstrao de recursos em di-

ferentes aspectos da computao. O conceito virtualizao" foi concebido pela
rea de TI para se referir a tudo que quisessem dizer sobre mquinas virtuais e a
softwares da gerncia de sistemas, o que acaba tornando o sentido do termo muito
amplo.

G UIA DE C LUSTER 14.1.1 - V IRTUALIZAO POR software
14.1.1 Virtualizao por software
Uma mquina virtual um ambiente que se apresenta como um sistema operaci-

onal convidado", mas simulado em um ambiente de software dentro do sistema
hospedeiro1 . A simulao dos drivers do hardware deve ser muito robusta para o
sistema hospedeiro funcionar corretamente. A criao e a gerncia de mquinas
virtuais so freqentemente consultadas pelo software de vitrualizao tambm
chamado de servidor de virtualizao. H diversas solues, considerando:
Emulao, a mquina virtual simula todo o hardware, permitindo que um

Sistema Operacional sem modificaes rode em um processador central
completamente diferente do hardware nativo. (Bochs, PearPC, verses do
virtual PC para PPC, Qemu sem acelerao)
Virtualizao nativa ou virtualizao cheia", a mquina virtual somente

simula parcialmente o hardware para permitir que um Sistema Operacional
sem modificaes funcione isoladamente no hardware, mas o Sistema Ope-
racional convidado deve ser projetado para o tipo de processador central.
(VMware, Parallels Desktop, Adeos, Mac-on-Linux, XEN)
Paravirtualizao, a mquina virtual no simula o hardware mas oferece

preferencialmente um API especial que requer modificaes no kernel do
Sistema Operacional hospede. As chamadas de sistema ao hypervisor co-
nhecida como paravirtualizao no XEN.
Virtualizao no nvel do sistema operacional, Virtualiza um servidor no

nvel do sistema operacional, permitindo o mltiplos isolamentos de modo
seguro aos servidores virtualizados, em um nico servidor fsico. Os am-
bientes dos Sistemas Operacionais hospedes so os mesmos que o do Sis-
tema hospedeiro, j que o mesmo kernel do hardware usado para executar
os ambientes no hospedeiro. (Linux-VServer, Virtuozzo e OpenVZ, Solaris
Containers, User Mode Linux e FreeBSD Jails)
A Virtualizao de aplicao envolve o uso de uma aplicao desktop ou ser-

ver localmente, sem ser instalado (comparado com os sistemas de instalao e
1
O hardware propriamente dito, ou seja, o sistema base que ir receber os outros sistemas ope-
racionais.

G UIA DE C LUSTER 14.1.2 - V IRTUALIZAO NATIVA
terminal services). A aplicao virtualizada roda em um pequeno ambiente

virtual que contm as entradas de registro, arquivos e outros componentes ne-
cessrios para execuo. Este ambiente virtual age como uma camada entre a
aplicao e o sistema operacional e elimina conflitos entre a aplicao e as aplica-
es do sistema operacional. (Softricity, Thinstall, Appstream, Ardence, Trigence,
Neoware)
14.1.2 Virtualizao nativa
Virtualizao nativa, tambm conhecida como virtualizao acelerada ou h-

brida, uma combinao de virtualizao nativa e virtualizao de I/O (entrada
e sada). Tipicamente, este mtodo iniciado com um VMM (Virtual Machine
Monitor) com suporte a virtualizao cheia, como o Xen por exemplo, e ento,
baseando-se na anlise de desempenho, emprega as tcnicas de acelerao. O
uso do processador e tambm dos drivers de rede so os recursos mais comuns,
onde empregada a virtualizao nativa.
Uma tcnica similar virtualizao nativa usada em mainframes. Na virtua-

lizao de hardwares x86, a primeira implementao de virtualizao nativa foi
feita com o software Virtual Iron http://www.virtualiron.com.
Uma vantagem da virtualizao nativa, que esta reduz a maioria das despe-
sas de manuteno da paravirtualizao no que tange a quantidade de alteraes
necessrias no sistema operacional convidado, e tambm obtm tambm consi-
dervel ganho de desempenho comparando com paravirtualizao.
Uma desvantagem da virtualizao nativa requerer que o convidado carregue

mdulos que podem afetar a sua sustentao. Ainda, existe uma certa limitao
quanto ao nmero de sistemas operacionais convidados rodando eficientemente
em uma VMM. provvel que, com as novas tecnologias de virtualizao nativa
de X86 e X86_64 da Intel (Vander Pool) e da AMD (Pacifica), o alcance de melhoras
nestes quesitos possam estar sendo alcanados. Equipes tcnicas de ambas as
empresas tem colaborado com o projeto Xen, o que pode trazer bons frutos para
a ferramenta.

G UIA DE C LUSTER 14.2 - XEN - Xen virtual machine monitor
14.2 XEN - Xen virtual machine monitor
Xen um Monitor de Mquinas Virtuais (VMM) que prov uma camada de abs-
trao entre o hardware e o sistema operacional virtualizado. Todo o cdigo do
micro-kernel e das aplicaes da VMM do Xen est sob GPL.
Xen prov paravirtualizao de Sistemas Operacionais com alteraes no kernel

para a arquitetura xen em hardwares x86/x86_64 e full virtualization em hardwares
x86/x86_64 com suporte a virtualizao assistida sem necessidade de modifica-
es do sistema operacional hospede.
O Xen mantido pela Universidade de Cambridge e conta com apoio de empre-

sas globais da rea de tecnologia da informao tais como IBM, HP, Intel, AMD
entre outras. Para maiores informaes acesse o stio do projeto na Universidade
de Cambridge http://www.cl.cam.ac.uk/Research/SRG/netos/xen/ ou o s-
tio Xen Sources http://www.xensource.com.
Alguns ports do Xen esto disponveis para outros sistemas operacionais como
NetBSD, FreeBSD e Solaris.
A dependncia do Sistema Operacional de um hardware exclusivo parece estar se

tornando coisa do passado. No futuro se pretende ter um Sistema Operacional
que no dependa exclusivamente do hardware e de sua localizao geogrfica.
O Xen nasceu do projeto NetOS (Networks and Operating Systems), criado pelo
Computer Laboratorys Systems Research Group" e pretende, como o prprio
nome do projeto pai sugere, criar uma camada de abstrao onde o Sistema Ope-
racional navegue" nos recursos dos servidores por uma rede TCP/IP.
Trazendo estes conceitos para o presente, imagine o seguinte cenrio: poderemos

estar acessando dados de uma determinada aplicao em um dado momento no
tempo rodando em um servidor fsico no Brasil e em outro momento estes mes-
mos dados estar localizado em outro continente sem que ao menos o usurio que
os acessa perceba a mudana geogrfica do Sistema Operacional.
Aliando-se sistemas de balanceamento de carga, alta disponibilidade, consoli-

dao de recursos computacionais e sistemas de arquivos em cluster, esta tarefa

G UIA DE C LUSTER 14.2.1 - C OMPARAO
parece estar se materializando.
14.2.1 Comparao
Ao contrrio do VMWare, o Xen executado diretamente sobre o hardware, no ring

0, e possui uma mquina virtual chamada de Dom0. Essa mquina tem acesso pri-
vilegiado ao hypervisor, permitindo a ela as operaes necessrias que as demais
mquinas virtuais no podem executar. A mquina virtual Dom0 ento respon-
svel pelo gerenciamento de toda a estrutura de gerenciamento de virtualizao
fazendo uso de aplicaes que tem acesso ao hypervisor. nesta mquina vir-
tual que se parametriza a virtualizao do hardware e a fatia entregue para cada
mquina virtual que no tenha acesso direto ao hardware e ao hypervisor.
No stio da Sun http://www.sun.com/emrkt/innercircle/newsletter/

brazil/0706vass.html, so feitas algumas ponderaes sobre tecnologias de
virtualizao:
Vmware:
Embora atraente, a abordagem de mquina virtual do VMware pode ser
relativamente cara em termos de desempenho. Geralmente, o hypervisor
consome entre 5 e 15% da potncia total da CPU, enquanto cada sistema
operacional aumenta a carga. No final, as empresas podem consumir uma
grande quantidade de recursos da CPU simplesmente para comportar a
infra-estrutura de mquina virtual.
Xen:
Recentemente, o software de cdigo aberto, Xen, surgiu como alternativa ao
VMware. Como o VMware, o Xen suporta a execuo de vrios sistemas
operacionais no mesmo hardware. O Xen uma forma de virtualizao de
nvel mais baixo, com a qual os administradores podem virtualizar vrias
partes de um sistema, incluindo a memria e a CPU. Como ele reside a
um nvel baixo, este oferece isolamento de falhas e recursos computacionais
considerveis.
H vrios motivos para se considerar o Xen:

G UIA DE C LUSTER 14.2.2 - S ISTEMA O PERACIONAL NATIVO VERSUS VIRTUALIZAO COM X EN
um programa de cdigo aberto,
relativamente leve, portanto, no consome uma quantidade absurda de

recursos da CPU.
atinge um alto grau de isolamento entre as tecnologias de mquina virtual.
como qualquer outra tecnologia de mquina virtual, suporta combinaes

variadas de sistemas operacionais e verses, alm de permitir que os ad-
ministradores iniciem e executem dinamicamente uma instncia do sistema
operacional sem afetar o servio.
14.2.2 Sistema Operacional nativo versus virtualizao com Xen
Algumas justificativas so vlidas para a utilizao de virtualizao. Ainda no

stio da Sun http://www.sun.com/emrkt/innercircle/newsletter/brazil/
0106feature.html:
A popularidade da virtualizao tem a ver com seu princpio filo-

sfico - a convico de que os data centers esto abarrotados de ser-
vidores subutilizados. Ela parece solucionar o problema criado pelo
paradigma predominante do um servidor para um aplicativo que re-
sulta do super-provisionamento visando mxima performance. As
taxas de utilizao de servidores podem oscilar entre 5% e 15%. Por
fim, a promessa de servidores baseados em commodities resultou em
data centers excessivamente caros de gerenciar, alimentar e refrigerar."
Esta afirmao faz cair por terra a tese de que necessrio o uso de um ser-
vidor por aplicao", considerando que servidor neste caso subentendido por
hardware. As taxas de utilizao do processador do hardware podem ser melhor
aproveitadas utilizando sistemas de virtualizao, aumentando o uso dos proces-
sadores (o Xen prov virtualizao dos processadores ou mesmo balanceamento
de carga entre eles), reduzindo o espao fsico do Data Center e em contra par-
tida reduzindo o consumo de energia eltrica para a alimentao dos servidores
e conseguentemente para outros tens como condicionador de ar.

G UIA DE C LUSTER 14.2.3 - PARAVIRTUALIZAO NO X EN
Ainda, com Xen possvel manter um SLA muito interessante. A possibilidade

de dar manuteno fsica nos servidores sem necessidade de parada dos servios
um diferencial que todo administrador deseja ter para no sofrer no momento
da parada de um hardware. Basta para isso ter um outro servidor configurado e
migrar em tempo real (50ms) o sistema operacional de um domnio para outro.
Esta migrao em tempo real (live migration) exige, no entanto, que certos aspec-
tos de configurao do ambiente sejam respeitados para que ela possa acontecer.
Estes requisitos so os seguintes:
Ambos os hosts (origem e destino da mquina virtual) devem executar um

daemon chamado xend, que a parte do VMM responsvel pela gerncia
das mquinas virtuais;
Ambos os hosts devem executar a mesma verso do Xen;
Ambos os hosts devem estar na mesma rede;
Ambos os hosts devem ter acesso ao sistema de arquivos utilizado pelos

guests. Na prtica, isto significa que deve haver um sistema de arquivos
compartilhado (por exemplo, NFS) visvel aos hosts;
O host de destino deve possuir memria livre o suficiente para acomodar a

nova mquina virtual.
Se estes requisitos no puderem ser atendidos, ainda possvel que seja realizada
a migrao. No entanto, a migrao realizada ser mais lenta e envolver a sus-
penso da atividade do sistema em migrao, suspenso esta que ser percebida
pelos clientes remotos utilizando as aplicaes presentes na mquina virtual.
14.2.3 Paravirtualizao no Xen
O Xen usa uma tcnica completamente diferente do que conceitualmente utili-

zada em outros hypervisors. Na paravirtualizao, o Sistema Operacional hospede
portado para uma camada de hardware (ring 1) que virtualiza todas as relaes
do Sistema Operacional com o hardware. Quando o Sistema Operacional atualiza
estruturas de dados do hardware, tais como a tabela de paginao ou da incio a

G UIA DE C LUSTER 14.2.3 - PARAVIRTUALIZAO NO X EN
uma operao do acesso direto da memria, o Sistema Operacional hospede faz

chamadas na API que oferecida pelo hypervisor.
Isto, por sua vez, permite que o hypervisor mantenha o controle de todas as mu-
danas feitas pelo Sistema Operacional, e decida como modificar as interrupes
do hardware. O hypervisor mapeado no endereo de cada Sistema Operacional
hospede, minimizando o tempo do interrupo entre todo o hardware e o hyper-
visor. Finalmente, trabalhando cooperativamente com os Sistemas Operacionais
hospedes, o hypervisor ganha a introspeco adicional do Sistema Operacional, e
pode fazer com que ele fique ciente do fato que foi virtualizado. Isto pode ser
uma grande vantagem para o sistema hospedeiro - por exemplo: o hypervisor
pode informar ao hospede em real-time qual foi sua ltima atividade, permitindo
um reescalonamento bem mais eficiente dos sistemas hospedados.
A paravirtualizao disponibiliza benefcios significantes em termos de drivers

de dispositivos e interfaces. Essencialmente, drivers de dispositivos podem ser
virtualizados utilizando o modelo de paravirtualizao, e assim, garantindo re-
cursos de baixo nvel separados por domnios como memria, CPU e outros re-
cursos. Alm disso, o prprio hypervisor protegido de eventuais erros e pro-
blemas com os drivers dos dispositivos e ainda pode-se empregar qualquer dis-
positivo disponvel no mercado no precisando assim um hardware ou driver es-
pecifico. E ainda, sistemas Operacionais virtualizados so muito mais portveis
quando virtualizados pelo hardware: eles so virtualizados em nveis baixos e, a
gerncia do hardware so mdulos que funcionam sob o controle do hypervisor.

Parte IV
Apndices

Apndice A
Licena CC-GNU GPL
Figura A.1: Creative Commons
Licena Pblica Geral do GNU (GPL) [General Public License]
Verso 21 , Junho de 1991 Direitos Autorais Reservados (c) 1989, 1991 Free Software
Foundation, Inc. 59 Temple Place, Suite [conjunto] 330, Boston, MA [Massachu-
setts] 02111-1307 USA [Estados Unidos da Amrica]
permitido a qualquer pessoa copiar e distribuir cpias sem alteraes deste

documento de licena, sendo vedada, entretanto, qualquer modificao.
Introduo
As licenas da maioria dos softwares so elaboradas para suprimir sua liberdade

de compartilh-los e modific-los. A Licena Pblica Geral do GNU, ao contrrio,
1
Disponvel em http://creativecommons.org/licenses/GPL/2.0/legalcode.pt.

G UIA DE C LUSTER CAPTULO A : L ICENA CC-GNU GPL
visa garantir sua liberdade de compartilhar e modificar softwares livres para asse-
gurar que o software seja livre para todos os seus usurios. Esta Licena Pblica
Geral aplicvel maioria dos softwares da Free Software Foundation [Fundao
do Software livre] e a qualquer outro programa cujos autores se comprometerem
a us-la. (Em vez dela, alguns outros softwares da Free Software Foundation so
cobertos pela Licena Pblica Geral de Biblioteca do GNU). Voc tambm poder
aplic-la aos seus programas.
Quando falamos de Software Livre, estamos nos referindo liberdade, no ao

preo. Nossas Licenas Pblicas Gerais visam garantir que voc tenha a liberdade
de distribuir cpias de Software Livre (e cobrar por isso se desejar), que receba
cdigo-fonte ou possa obt-lo se desejar, que possa modific-lo ou usar partes
dele em novos programas livres; finalmente, que voc tenha cincia de que pode
fazer tudo isso.
Para proteger seus direitos, necessitamos fazer restries que probem que al-
gum negue esses direitos a voc ou que solicite que voc renuncie a eles. Essas
restries se traduzem em determinadas responsabilidades que voc dever as-
sumir, se for distribuir cpias do software ou modific-lo.
Por exemplo, se voc distribuir cpias de algum desses programas, tanto gratui-
tamente como mediante uma taxa, voc ter de conceder aos receptores todos os
direitos que voc possui. Voc ter de garantir que, tambm eles, recebam ou pos-
sam obter o cdigo-fonte. E voc ter a obrigao de exibir a eles esses termos,
para que eles conheam seus direitos.
Protegemos seus direitos atravs de dois passos: (1) estabelecendo direitos auto-
rais sobre o software e (2) concedendo a voc esta licena, que d permisso legal
para copiar, distribuir e/ou modificar o software.
Alm disso, para a proteo de cada autor e a nossa, queremos ter certeza de que
todos entendam que no h nenhuma garantia para este Software Livre. Se o soft-
ware for modificado por algum e passado adiante, queremos que seus receptores
saibam que o que receberam no o original, de forma que quaisquer problemas
introduzidos por terceiros no afetem as reputaes dos autores originais.
Finalmente, qualquer programa livre constantemente ameaado por patentes

de software. Queremos evitar o risco de que redistribuidores de um programa li-

vre obtenham individualmente licenas sob uma patente, tornando o programa,

com efeito, proprietrio. Para impedir isso, deixamos claro que qualquer patente
deve ser licenciada para o uso livre por parte de qualquer pessoa ou, ento, sim-
plesmente no deve ser licenciada.
Os exatos termos e condies para cpia, distribuio e modificao seguem

abaixo. TERMOS E CONDIES PARA CPIA, DISTRIBUIO E MODIFI-
CAO.
1. Esta Licena se aplica a qualquer programa ou outra obra que contenha

um aviso inserido pelo respectivo titular dos direitos autorais, informando
que a referida obra pode ser distribuda em conformidade com os termos
desta Licena Pblica Geral. O termo Programa, utilizado abaixo, refere-
se a qualquer programa ou obra, e o termo obras baseadas no Programa
significa tanto o Programa, como qualquer obra derivada nos termos da le-
gislao de direitos autorais: isto , uma obra contendo o Programa ou uma
parte dele, tanto de forma idntica como com modificaes, e/ou traduzida
para outra linguagem. (Doravante, o termo modificao inclui tambm,
sem reservas, a traduo). Cada licenciado, doravante, ser denominado
voc.
Outras atividades que no a cpia, distribuio e modificao, no so co-

bertas por esta Licena; elas esto fora de seu escopo. O ato de executar
o Programa no tem restries e o resultado gerado a partir do Programa
encontra-se coberto somente se seu contedo constituir uma obra baseada
no Programa (independente de ter sido produzida pela execuo do Pro-
grama). Na verdade, isto depender daquilo que o Programa faz.
2. Voc poder fazer cpias idnticas do cdigo-fonte do Programa ao receb-

lo e distribui-las, em qualquer mdia ou meio, desde que publique, de forma
ostensiva e adequada, em cada cpia, um aviso de direitos autorais (ou
copyright) apropriado e uma notificao sobre a exonerao de garantia;
mantenha intactas as informaes, avisos ou notificaes referentes a esta
Licena e ausncia de qualquer garantia; e fornea a quaisquer outros re-
ceptores do Programa uma cpia desta Licena junto com o Programa.
Voc poder cobrar um valor pelo ato fsico de transferir uma cpia, e voc
pode oferecer, se quiser, a proteo de uma garantia em troca de um valor.

3. Voc poder modificar sua cpia ou cpias do Programa ou qualquer parte

dele, formando, dessa forma, uma obra baseada no Programa, bem como
copiar e distribuir essas modificaes ou obra, de acordo com os termos
da Clusula 1 acima, desde que voc tambm atenda a todas as seguintes
condies:
a. Voc deve fazer com que os arquivos modificados contenham avisos,

em destaque, informando que voc modificou os arquivos, bem como
a data de qualquer modificao.
b. Voc deve fazer com que qualquer obra que voc distribuir ou publicar,
que no todo ou em parte contenha o Programa ou seja dele derivada,
ou derivada de qualquer parte dele, seja licenciada como um todo sem
qualquer custo para todos terceiros nos termos desta licena.
c. Se o programa modificado normalmente l comandos interativamente
quando executado, voc dever fazer com que ele, ao comear a ser
executado para esse uso interativo em sua forma mais simples, im-
prima ou exiba um aviso incluindo o aviso de direitos autorais (ou
copyright) apropriado, alm de uma notificao de que no h garan-
tia (ou, ento, informando que voc oferece garantia) e informando
que os usurios podero redistribuir o programa de acordo com essas
condies, esclarecendo ao usurio como visualizar uma cpia desta
Licena. (Exceo: se o Programa em si for interativo mas no impri-
mir normalmente avisos como esses, no obrigatrio que a sua obra
baseada no Programa imprima um aviso).
Essas exigncias se aplicam obra modificada como um todo. Se par-
tes identificveis dessa obra no forem derivadas do Programa e pu-
derem ser consideradas razoavelmente como obras independentes e
separadas por si prprias, nesse caso, esta Licena e seus termos no
se aplicaro a essas partes quando voc distribui-las como obras se-
paradas. Todavia, quando voc distribui-las como parte de um todo
que constitui uma obra baseada no Programa, a distribuio deste todo
ter de ser realizada em conformidade com esta Licena, cujas permis-
ses para outros licenciados se estendero obra por completo e, con-
seqentemente, a toda e qualquer parte, independentemente de quem
a escreveu.
Portanto, esta clusula no tem a inteno de afirmar direitos ou con-
testar os seus direitos sobre uma obra escrita inteiramente por voc;

a inteno , antes, de exercer o direito de controlar a distribuio de

obras derivadas ou obras coletivas baseadas no Programa.
Alm do mais, a simples agregao de outra obra que no seja baseada
no Programa a ele (ou a uma obra baseada no Programa) em um vo-
lume de mdia ou meio de armazenamento ou distribuio, no inclui
esta outra obra no mbito desta Licena.
4. Voc poder copiar e distribuir o Programa (ou uma obra baseada nele, de
acordo com a Clusula 2) em cdigo-objeto ou formato executvel de acordo
com os termos das Clusulas 1 e 2 acima, desde que voc tambm tome uma
das providncias seguintes:
a. Incluir o cdigo-fonte correspondente completo, passvel de leitura

pela mquina, o qual ter de ser distribudo de acordo com as Clu-
sulas 1 e 2 acima, em um meio ou mdia habitualmente usado para
intercmbio de software; ou,
b. Incluir uma oferta por escrito, vlida por pelo menos trs anos, para
fornecer a qualquer terceiro, por um custo que no seja superior ao
seu custo de fisicamente realizar a distribuio da fonte, uma cpia
completa passvel de leitura pela mquina, do cdigo-fonte correspon-
dente, a ser distribudo de acordo com as Clusulas 1 e 2 acima, em um
meio ou mdia habitualmente usado para intercmbio de software; ou,
c. Incluir as informaes recebidas por voc, quanto oferta para distri-
buir o cdigo-fonte correspondente. (Esta alternativa permitida so-
mente para distribuio no-comercial e apenas se voc tiver recebido
o programa em cdigo-objeto ou formato executvel com essa oferta,
de acordo com a letra b, acima).
O cdigo-fonte de uma obra significa o formato preferencial da obra
para que sejam feitas modificaes na mesma. Para uma obra execut-
vel, o cdigo-fonte completo significa o cdigo-fonte inteiro de todos
os mdulos que ela contiver, mais quaisquer arquivos de definio de
interface associados, alm dos scripts usados para controlar a compila-
o e instalao do executvel. Entretanto, como uma exceo especial,
o cdigo-fonte distribudo no precisa incluir nada que no seja nor-
malmente distribudo (tanto no formato fonte como no binrio) com
os componentes principais (compilador, kernel e assim por diante) do
sistema operacional no qual o executvel executado, a menos que
este componente em si acompanhe o executvel.

Se a distribuio do executvel ou cdigo-objeto for feita mediante a

permisso de acesso para copiar, a partir de um local designado, ento,
a permisso de acesso equivalente para copiar o cdigo-fonte a partir
do mesmo local ser considerada como distribuio do cdigo-fonte,
mesmo que os terceiros no sejam levados a copiar a fonte junto com o
cdigo-objeto.
5. Voc no poder copiar, modificar, sublicenciar ou distribuir o Programa,

exceto conforme expressamente estabelecido nesta Licena. Qualquer ten-
tativa de, de outro modo, copiar, modificar, sublicenciar ou distribuir o Pro-
grama ser invlida, e automaticamente rescindir seus direitos sob esta
Licena. Entretanto, terceiros que tiverem recebido cpias ou direitos de
voc de acordo esta Licena no tero suas licenas rescindidas, enquanto
estes terceiros mantiverem o seu pleno cumprimento.
6. Voc no obrigado a aceitar esta Licena, uma vez que voc no a assinou.
Porm, nada mais concede a voc permisso para modificar ou distribuir
o Programa ou respectivas obras derivativas. Tais atos so proibidos por
lei se voc no aceitar esta Licena. Conseqentemente, ao modificar ou
distribuir o Programa (ou qualquer obra baseada no Programa), voc estar
manifestando sua aceitao desta Licena para faz-lo, bem como de todos
os seus termos e condies para copiar, distribuir ou modificar o Programa
ou obras nele baseadas.
7. Cada vez que voc redistribuir o Programa (ou obra baseada no Programa),
o receptor receber, automaticamente, uma licena do licenciante original,
para copiar, distribuir ou modificar o Programa, sujeito a estes termos e con-
dies. Voc no poder impor quaisquer restries adicionais ao exerccio,
pelos receptores, dos direitos concedidos por este instrumento. Voc no
tem responsabilidade de promover o cumprimento por parte de terceiros
desta licena.
8. Se, como resultado de uma sentena judicial ou alegao de violao de pa-

tente, ou por qualquer outro motivo (no restrito s questes de patentes),
forem impostas a voc condies (tanto atravs de mandado judicial, con-
trato ou qualquer outra forma) que contradigam as condies desta Licena,
voc no estar desobrigado quanto s condies desta Licena. Se voc
no puder atuar como distribuidor de modo a satisfazer simultaneamente
suas obrigaes sob esta licena e quaisquer outras obrigaes pertinentes,

ento, como conseqncia, voc no poder distribuir o Programa de ne-

nhuma forma. Por exemplo, se uma licena sob uma patente no permite a
redistribuio por parte de todos aqueles que tiverem recebido cpias, di-
reta ou indiretamente de voc, sem o pagamento de royalties, ento, a nica
forma de cumprir tanto com esta exigncia quanto com esta licena ser
deixar de distribuir, por completo, o Programa.
Se qualquer parte desta Clusula for considerada invlida ou no execu-
tvel, sob qualquer circunstncia especfica, o restante da clusula dever
continuar a ser aplicado e a clusula, como um todo, dever ser aplicada
em outras circunstncias.
Esta clusula no tem a finalidade de induzir voc a infringir quaisquer pa-
tentes ou direitos de propriedade, nem de contestar a validade de quaisquer
reivindicaes deste tipo; a nica finalidade desta clusula proteger a inte-
gridade do sistema de distribuio do Software Livre, o qual implementado
mediante prticas de licenas pblicas. Muitas pessoas tm feito generosas
contribuies ampla gama de software distribudo atravs desse sistema,
confiando na aplicao consistente deste sistema; cabe ao autor/doador de-
cidir se deseja distribuir software atravs de qualquer outro sistema e um
licenciado no pode impor esta escolha.
Esta clusula visa deixar absolutamente claro o que se acredita ser uma con-
seqncia do restante desta Licena.
9. Se a distribuio e/ou uso do Programa for restrito em determinados pa-

ses, tanto por patentes ou por interfaces protegidas por direito autoral, o
titular original dos direitos autorais que colocar o Programa sob esta Li-
cena poder acrescentar uma limitao geogrfica de distribuio explcita
excluindo esses pases, de modo que a distribuio seja permitida somente
nos pases ou entre os pases que no foram excludos dessa forma. Nesse
caso, esta Licena passa a incorporar a limitao como se esta tivesse sido
escrita no corpo desta Licena.
10. A Free Software Foundation poder de tempos em tempos publicar no-

vas verses e/ou verses revisadas da Licena Pblica Geral. Essas no-
vas verses sero semelhantes em esprito presente verso, mas podem
diferenciar-se, porm, em detalhe, para tratar de novos problemas ou preo-
cupaes.
Cada verso recebe um nmero de verso distinto. Se o Programa especifi-
car um nmero de verso desta Licena que se aplique a ela e a qualquer

verso posterior, voc ter a opo de seguir os termos e condies tanto

daquela verso como de qualquer verso posterior publicada pela Free Soft-
ware Foundation. Se o Programa no especificar um nmero de verso desta
Licena, voc poder escolher qualquer verso j publicada pela Free Soft-
ware Foundation.
11. Se voc desejar incorporar partes do Programa em outros programas livres

cujas condies de distribuio sejam diferentes, escreva ao autor solici-
tando a respectiva permisso. Para software cujos direitos autorais sejam da
Free Software Foundation, escreva para ela; algumas vezes, abrimos exce-
es para isso. Nossa deciso ser guiada pelos dois objetivos de preservar
a condio livre de todos os derivados de nosso Software Livre e de promo-
ver o compartilhamento e reutilizao de software, de modo geral.
EXCLUSO DE GARANTIA
11. COMO O PROGRAMA LICENCIADO SEM CUSTO, NO H NE-

NHUMA GARANTIA PARA O PROGRAMA, NO LIMITE PERMITIDO
PELA LEI APLICVEL. EXCETO QUANDO DE OUTRA FORMA ESTA-
BELECIDO POR ESCRITO, OS TITULARES DOS DIREITOS AUTORAIS
E/OU OUTRAS PARTES, FORNECEM O PROGRAMA NO ESTADO
EM QUE SE ENCONTRA, SEM NENHUMA GARANTIA DE QUAL-
QUER TIPO, TANTO EXPRESSA COMO IMPLCITA, INCLUINDO, DEN-
TRE OUTRAS, AS GARANTIAS IMPLCITAS DE COMERCIABILIDADE
E ADEQUAO A UMA FINALIDADE ESPECFICA. O RISCO INTE-
GRAL QUANTO QUALIDADE E DESEMPENHO DO PROGRAMA
ASSUMIDO POR VOC. CASO O PROGRAMA CONTENHA DEFEITOS,
VOC ARCAR COM OS CUSTOS DE TODOS OS SERVIOS, REPAROS
OU CORREES NECESSRIAS.
12. EM NENHUMA CIRCUNSTNCIA, A MENOS QUE EXIGIDO PELA LEI

APLICVEL OU ACORDADO POR ESCRITO, QUALQUER TITULAR DE
DIREITOS AUTORAIS OU QUALQUER OUTRA PARTE QUE POSSA MO-
DIFICAR E/OU REDISTRIBUIR O PROGRAMA, CONFORME PERMI-
TIDO ACIMA, SER RESPONSVEL PARA COM VOC POR DANOS,
INCLUINDO ENTRE OUTROS, QUAISQUER DANOS GERAIS, ESPECI-
AIS, FORTUITOS OU EMERGENTES, ADVINDOS DO USO OU IMPOS-
SIBILIDADE DE USO DO PROGRAMA (INCLUINDO, ENTRE OUTROS,

PERDAS DE DADOS OU DADOS SENDO GERADOS DE FORMA IMPRE-

CISA, PERDAS SOFRIDAS POR VOC OU TERCEIROS OU A IMPOSSI-
BILIDADE DO PROGRAMA DE OPERAR COM QUAISQUER OUTROS
PROGRAMAS), MESMO QUE ESSE TITULAR, OU OUTRA PARTE, TE-
NHA SIDO ALERTADA SOBRE A POSSIBILIDADE DE OCORRNCIA
DESSES DANOS.
FINAL DOS TERMOS E CONDIES
Como Aplicar Estes Termos para Seus Novos Programas.
Se voc desenvolver um programa novo e quiser que ele seja da maior utilidade
possvel para o pblico, o melhor caminho para obter isto fazer dele um Soft-
ware Livre, o qual qualquer pessoa pode redistribuir e modificar sob os presentes
termos.
Para fazer isto, anexe as notificaes seguintes ao programa. mais seguro anex-
las ao comeo de cada arquivo-fonte, de modo a transmitir do modo mais efici-
ente a excluso de garantia; e cada arquivo deve ter ao menos a linha de direitos
autorais reservados e uma indicao de onde a notificao completa se encontra.
<uma linha para informar o nome do programa e uma breve idia do

que ele faz.> Direitos Autorais Reservados (c) <nome do autor> Este
programa Software Livre; voc pode redistribu-lo e/ou modific-
lo sob os termos da Licena Pblica Geral GNU conforme publicada
pela Free Software Foundation; tanto a verso 2 da Licena, como (a
seu critrio) qualquer verso posterior.
Este programa distribudo na expectativa de que seja til, porm,
SEM NENHUMA GARANTIA; nem mesmo a garantia implcita de
COMERCIABILIDADE OU ADEQUAO A UMA FINALIDADE
ESPECFICA. Consulte a Licena Pblica Geral do GNU para mais
detalhes.
Voc deve ter recebido uma cpia da Licena Pblica Geral do GNU
junto com este programa; se no, escreva para a Free Software Founda-
tion, Inc., no endereo 59 Temple Street, Suite 330, Boston, MA 02111-

1307 USA. Inclua tambm informaes sobre como contatar voc por
correio eletrnico e por meio postal.
Se o programa for interativo, faa com que produza uma pequena notificao
como esta, quando for iniciado em um modo interativo:
Verso 69 do Gnomovision, Direitos Autorais Reservados (c) ano

nome do autor. O Gnomovision NO POSSUI QUALQUER TIPO DE
GARANTIA; para detalhes, digite show w. Este um Software Li-
vre e voc bem-vindo para redistribu-lo sob certas condies; digite
show c para detalhes.
Os comandos hipotticos show w e show c devem mostrar as partes apropri-

adas da Licena Pblica Geral. Naturalmente, os comandos que voc utilizar
podero ter outras denominaes que no show w e show c; eles podero at
ser cliques do mouse ou itens de um menu o que for adequado ao seu programa.
Voc tambm pode solicitar a seu empregador (se voc for um programador) ou
sua instituio acadmica, se for o caso, para assinar uma renncia de direitos
autorais sobre o programa, se necessrio. Segue um exemplo; altere os nomes:
A Yoyodyne Ltda., neste ato, renuncia a todos eventuais direitos auto-

rais sobre o programa Gnomovision (que realiza passagens em com-
piladores), escrito por James Hacker.
<Assinatura de Ty Coon> 1o de abril de 1989, Ty Coon, Presidente
Esta Licena Pblica Geral no permite a incorporao do seu programa a progra-

mas proprietrios. Se seu programa uma biblioteca de sub-rotinas, voc poder
considerar ser mais til permitir a ligao de aplicaes proprietrias sua biblio-
teca. Se isso o que voc deseja fazer, utilize a Licena Pblica Geral de Biblioteca
do GNU, ao invs desta Licena.

Apndice B
Marcas Registradas
Foram utilizadas marcas registradas neste Documento com o propsito de iden-

tificao. A equipe de elaborao do Guia de Cluster reconhece a propriedade
dessas marcas registradas, conforme demonstrado na Tabela B.
Caso voc acredite que sua marca foi utilizada sem a devida referncia de propri-
edade, por favor, encaminhe uma mensagem para <guialivre@planejamento.
gov.br>, para que a equipe de redao possa regularizar a situao nas prximas
verses do Documento.
Tabela de Referncia de Marcas Registradas

Marcas Registradas Proprietrio
Apache, Tomcat, Jakarta Apache Foundation
AT&T AT&T
Apple, Mac OS Apple Computer, Inc
BSD University of California, Berkeley, USA
Citrix Citrix Systems, Inc.
Debian Software in the Public Interest, Inc
Firebird Firebird Project
FreeBSD Walnut Creek CDROM, Inc
HP/UX Hewlett-Packard Company
IBM, Lotus, MVS, AIX, AS/400, IBM Corporation
VM/CMS, DB2, GLOBUS
Interbase Borland Software Corporation

G UIA DE C LUSTER CAPTULO B : M ARCAS R EGISTRADAS
Marcas Registradas Proprietrio

MaxDB, MySQL, MySQL Cluster MySQL AB
Windows, Active Directory, ODBC, Mi- Microsoft Corporation
crosoft Exchange, SQL Server
NetBSD NetBSD Foundation
Novell, Netware, NDS Novell, Inc
Adabas Software/AG of North America, Inc
Oracle, OCFS, OCFS2 Oracle Corporation
PostgreSQL, Slonny, pgpoll, pgcluster PostgreSQL, Inc
Red Hat, GFS, GNBD, RHCS Red Hat, Inc
SuSE SuSE AG
Sun, Solaris, Java, JDBC Sun Microsystems, Inc
Sybase Sybase, Inc
Sequoia Continuent, Inc
Zope Zope Corporation
Tabela B.1: Tabela de Referncia de Marcas Registradas

Apndice C
Lista de Abreviaturas
API Application Programming Interface
APF Administrao Pblica Federal
ATM Assynchronous Transfer Mode
B2B Business to Business
B2C Business to Consumer
B2G business-to-government
BI Business Inteligence
BSP Bulk Synchronous Parallelism
C2C consumer-to-consumer
C2G consumer-to-government
CC Controle de Concorrncia

G UIA DE C LUSTER CAPTULO C : L ISTA DE A BREVIATURAS
CMOS Complementary Metal Oxide Semiconductor
DRAM Dynamic Random Access Memory
DSM Distributed Shared Memory
ECL Emmiter Coupled Logic
e-GOV Governo Eletrnico Brasileiro
Arquitetura e-PING Padres de Interopera-

e-PING
bilidade
ERP Enterprise Resource Planning
FDDI Fiber Distributed Data Interface
FFT Fast Fourier Transformation
FTP Protocolo de Transferncia de Arquivo
G2G government-to-government
HA Alta Disponibilidade
HIPPI High-Performance Parallel Interface
HPC Alta Capacidade de Processamento
HPF High Performance Fortran
HTTP Protocolo de Transferncia de Hipertexto

IP Internet Protocol
ISO International Organization for Standardization
LB Balanceamento de Carga
LVS Linux Virtual Server
Mbps Milhes de bits por segundo
Milhes de Instrues de Ponto Flutuante

MFLOPS
Por Segundo
Mltiplas seqncias de Instrues, Mlti-

MIMD
plas seqncias de Dados
MIPS Milhes de Instrues Por Segundo
Mltiplas Seqncias de Instrues, uma

MISD
Seqncia de Dados
MPI Message Passing Interface
NFS Network File System
MPP Processadores Massivamente Paralelos
NUMA NonUniform Memory Access
OLTP On Line Transaction Processing
Oracle RAC Oracle Real Aplication Cluster
OSI Open Systems Interconnection

PVM Parallel Virtual Machine
RFC Request for Comments
RPCs Remote Procedure Calls
RTP Real-time Transport Protocol
SAN Storage Area Network
SCI Scalable Coherent Interface
SGDB Sistema Gerenciador de Banco de Dados
Uma Seqncia de Instrues, Mltiplas

SIMD
Seqncias de Dados
Uma Seqncia de Instrues, uma

SISD
Seqncia de Dados
Secretaria de Logstica e Tecnologia da Informa-

SLTI
o
SMP Multiprocessadores Simtricos
SOA Arquitetura Orientada a Servios
SOAP Protocolo Simples para Acesso a Objetos
SONET Synchronous Optical NETwork
SPMD Simple Program Multiple Data
SR Synchronizing Resources

SRAM Static Random Access Memory
SSI Sistema de Imagem nica
TCP/IP Transmition Control Protocol/Internet Protocol
TIC Tecnologia da Informao e Comunicao
UDDI Descrio, Descoberta e Integrao Universais
UDP User Datagram Protocol
VRRP Virtual Router Redundancy Protocol
W3C Consrcio da Rede Mundial Web
WSDL Linguagem para definio de Servios Web
XDR External Data Representation
XEN Xen virtual machine monitor
XML eXtensible Markup Language
XMPP eXtensible Messaging and Presence Protocol
XSL eXtensible Stylesheet Language
Tabela C.1: Lista de Abreviaturas

G UIA DE C LUSTER CAPTULO D : T ECNOLOGIAS
Apndice D
Tecnologias
Tabela de referncias de tecnologias que so abordadas neste Guia.
Tabela de referncia de tecnologias

Software Licena Verso Site Oficial
HPC
Beowulf http://www.beowulf.org/
OpenSSI GPL v2 1.9.2 http://www.openssi.org/
Kerrighed GPL v2 1.0.2 http://www.kerrighed.org/
OpenMosix GPL v2 openMosix- http://openmosix.sourceforge.net/

(Mosix) kernel-
2.4.26
Storage
iSCSI GPL 4.0.x http://linux-iscsi.sourceforge.net/
gndb GPL 6.1 http://sourceware.org/cluster/gnbd/
drdb GPL 0.7 http://www.drbd.org/
endb GPL http://www.it.uc3m.es/ptb/nbd/
gfs GPL 6.1 http://www.redhat.com/software/rha/gfs/
ocfs2 GPL 1.2.3 http://oss.oracle.com/projects/ocfs2/
pvfs GPL 1.6.3 http://www.parl.clemson.edu/pvfs/
lustre GPL 1.4.7 http://www.lustre.org/
Cluster de Banco de Dados, Banco de Dados Distribuido

mysql clus- GPL e pro- 5.0 http://www.mysql.com/products/database/
ter
VERSAO 1.0
prietria cluster/ PGINA 369
G UIA DE C LUSTER CAPTULO D : T ECNOLOGIAS
Software Licena Verso Site Oficial

pgcluster BSD 1.3 http://pgcluster.projects.postgresql.org/
index.html
slony-l BSD 1.1.5 http://gborg.postgresql.org/project/

slony1/projdisplay.php
pgpool-I BSD 3.1.1 http://pgpool.projects.postgresql.org/
pgpool-II BSD 1.0.1 http://pgpool.projects.postgresql.org/

pgpool-II/en/
sequoia Apache Li- 2.10 http://sequoia.continuent.org/HomePage

cense 2
pargres GPL http://pargres.nacad.ufrj.br/
Alta Disponibilidade/Balanceamento de Carga

Heartbet GPL 2.0.7 http://www.linux-ha.org/
Carp BSD http://www.openbsd.org/faq/pf/pt/carp.

html
LVS GPL 1.2.1 http://www.linuxvirtualserver.org/
Keepalive GPL 1.1.12 http://www.keepalived.org/
Cluster de Aplicaes
Cluster ZPL 3.1 http://zope.delta.ncsu.edu/portal/delta/
ZOPE developers/projects/system_projects/zope_
cluster
Cluster Apache Li- 5.0 http://jakarta.apache.org

Tomcat cense 2
cluster Apache Li- 2.0 http://httpd.apache.org
Apache cense 2
Ferramentas de Gerenciamento de Cluster
ganglia BSD 3.0 http://ganglia.sourceforge.net/
Etherboot GPL v2 http://etherboot.sourceforge.net/
Tabela D.1: Tabela de referncias de tecnologias

G UIA DE C LUSTER CAPTULO E : G LOSSRIO
Apndice E
Glossrio
API (Application Programming O mtodo especfico recomendado por um sistema ope-

Interface) racional de computador, aplicativo ou ferramenta de ter-
ceiros, pelo qual um programador escrevendo um apli-
cativo pode fazer requisies do sistema operacional.
Tambm conhecido por Application Programmers Inter-
face.
APF - Administrao Pblica rene rgos da administrao direta (servios in-

Federal tegrados na estrutura administrativa da Presidn-
cia da Repblica e dos Ministrios) e indireta (Au-
tarquias, Empresas Pblicas, Sociedades de Econo-
mia Mista e Fundaes Pblicas) do Poder Execu-
tivo. https://www.planalto.gov.br/ccivil_
03/decreto-lei/del0200.htm
Assncrona O que no ocorre ao mesmo tempo; sem relao regu-

lar de tempo, inesperado, imprevisvel. Modo de trans-
misso no qual os dados so transmitidos sem periodi-
cidade constante (no modo sncrono, os dados so trans-
mitidos periodicamente); transmisso de sinais onde os
intervalos de tempo entre os caracteres transmitidos po-
dem ser diferentes, e a transmisso controlada por ele-
mentos que indicam o incio e o fim de cada caractere.
Transmisso que envia um caractere de cada vez. Trans-
misso assncrona a transmisso de dados que no
exige o uso de sinais externos para manter a sincroni-
VERSAO 1.0 zao entre emissor e receptor. PGINA 372
Bandwidth (largura de banda) Termo que designa o tempo gasto pelas vrias tecnolo-
Business to Business (B2B) Negcios feitos entre empresas, seus clientes, distribui-
dores e fornecedores, conectando seus sistemas de infor-
mao atravs da Internet.
Business to Consumer (B2C) Negcios feitos das empresas com seus consumidores,
ou seja, comrcio eletrnico com o consumidor final.
CERN (Conseil Europen Um dos mais importantes centros mundiais de pesqui-

pour la Recherche Nuclaire sas avanadas em Fsica Nuclear e de Partculas, loca-
/ Conselho Europeu para a lizado em Genebra/Suia. Um de seus pesquisadores,
Pesquisa Nuclear) Tim Berners Lee, foi o inventor, em 1989, do HTTP (Hy-
pertext Transfer Protocol), o protocolo usado na WWW
para transferir arquivos HTML.
CERT (Computer Emergency Organizao criada em 1988 que oferece servios de con-
Response Team) sulta para usurios da Internet e que entra em ao sem-
pre que um novo vrus e outras ameaas ao computado-
res so descobertas.
CORBA (Common Object Re- um padro para comunicao entre objetos distri-
quest Broker Architecture) budos. Prov diferentes formas para executar progra-
mas (objetos) desenvolvidos em diferentes linguagens
de programao e em diferentes plataformas.
CRP (Continuous Replenish- a prtica de parceria entre os membros do canal de dis-

ment Process) tribuio que altera o tradicional processo de reposio
de mercadoria de gerao de pedidos elaborados pelo
distribuidor, baseado em quantidades economicamente
convenientes, para a reposio de produtos baseada em
previso de demanda efetiva. Busca integrar, por meio
de prticas distintas, o fluxo de informaes e produtos.

Customer Relationship Manage- Gerenciamento do relacionamento com cliente a arte

ment (CRM) de integrar todos os aspectos da tecnologia da informa-
o em benefcio de um completo relacionamento com o
cliente, desde atividades de marketing e vendas at con-
tas a receber.
Data warehouse Armazm de dados, sistema que guarda e organiza to-

das as informaes espalhadas pelos vrios sistemas
dentro de uma empresa. Termo genrico para um tipo
de banco de dados que consiste num sistema de ar-
mazenamento, recuperao e gerenciamento de grandes
quantidades de quaisquer tipos de dados. Os softwares
da espcie freqentemente incluem sofisticadas tcnicas,
inclusive de compactao, para buscas mais rpidas de
dados, assim como filtros avanados.
DNS - Domain Name System forma como os nomes de domnio so encontrados e tra-
(Sistema de Nomes de Dom- duzidos no endereo de protocolo da Internet. Um nome
nio) de domnio um recurso fcil de ser lembrado quando
referenciado como um endereo na Internet.
EAI (Enterprise Application In- Integrao de Aplicaes entre Empresas um tipo de

tegration) tecnologia que permite o movimento e troca de informa-
es entre diferentes aplicaes e processos de negcios
entre e dentro de organizaes.
EDI (Electronic Data Inter- Intercmbio Eletrnico de Dados - tecnologia, que per-
change) mite troca de informaes (com modem e softwares ade-
quados) diretamente de computadores para computado-
res, dispensando digitao e manipulao de dados. O
sistema que a utiliza permite automatizar transaes co-
muns de negcios como ordens de compras, faturas, no-
tificaes de embarques etc. Atravs do EDI, documen-
tos so transmitidos e recebidos eletronicamente, inde-
pendente de horrios, distncia e dos sistemas de com-
putao utilizados. O resultado um fluxo de informa-
es rpido e preciso, no qual as mensagens vo e vol-
tam sem qualquer interferncia e com toda segurana,
atendendo aos desafios de maior agilidade e eficincia
na comunicao de negcios.
EJB (Enterprise JavaBeans) um padro de programao Java que permite que c-

digos escritos nesta linguagem e que sigam este padro,
possam ser distribudos e executados em servidores de
aplicao de EJB (EJB Servers).
ERP (Enterprise Resource Plan- Planejamento de recursos corporativos atravs de siste-

ning) mas integrados de gesto implementados por softwares;
um programa integrado de gesto empresarial, geral-
mente dividido em diversos mdulos, como o de admi-
nistrao, o financeiro, de manufatura etc.
FTP - File Transfer Protocol um protocolo aplicativo que utiliza os protocolos

(Protocolo de Transferncia TCP/IP da Internet, sendo a maneira mais simples de
de Arquivo) trocar arquivos entre computadores na Internet.
HTTP - Hyper Text Transfer conjunto de regras para permuta de arquivos (texto,
Protocol (Protocolo de Trans- imagens grficas, som, vdeo e outros arquivos multi-
ferncia de Hipertexto) mdia) na World Wide Web.
IEEE - Institute of Electri- fomenta o desenvolvimento de padres e normas que

cal and Electronics Engineers freqentemente se tornam nacionais e internacionais.
(Instituto de Engenheiros El-
tricos e Eletrnicos)
IETF - Internet Engineering entidade que define protocolos operacionais padro da

Task Force (Fora Tarefa de En- Internet, como o TCP/IP.
genharia da Internet)
Internet Rede mundial de computadores que utiliza a arquite-

tura de protocolos de comunicao TCP/IP. Originou-se
de um sistema de telecomunicaes descentralizado cri-
ado pelo Depto de Defesa dos Estados Unidos durante
a Guerra Fria. Durante os anos 70 e 80, cresceu entre os
meios acadmicos, quando sua principal aplicao era o
correio eletrnico. Com a apario da World Wid Web
em 1993, a Internet se popularizou. Prov transferncias
de arquivos, login remoto, correio eletrnico, news, na-
vegao na Web e outros servios.

JDBC Java Database Connectivity. Uma especificao de inter-

face de programa aplicativo (application program interface
- API) para conectar programas escritos em Java aos da-
dos em bancos de dados populares. A interface de pro-
grama aplicativo permite que se codifiquem declaraes
de requisio de acesso em Structured Query Language
(SQL), as quais so ento passadas para o programa que
gerencia o banco de dados. O resultado retornado por
uma interface similar.
Metadados so informaes adicionais necessrias para que os da-

dos se tornem teis. informao essencial para que
se possa fazer uso dos dados. Em suma, metada-
dos so um conjunto de caractersticas sobre os dados
que no esto normalmente includas nos dados propri-
amente ditos. http://www.isa.utl.pt/dm/sig/
sig20002001/TemaMetadados/trabalho.htm
Middleware um termo geral que serve para mediar dois programas

separados e normalmente j existentes. Aplicaes dife-
rentes podem comunicar-se atravs do servio de Mes-
saging, proporcionado por programas middleware.
NFS (Network File System) o protocolo de compartilhamento de arquivos remo-

tos desenvolvido pela Sun Microsystems. Faz parte da
famlia de protocolos TCP/IP.
NNTP (Network News Transfer Padro usado para a troca de mensagens dos usurios
Protocol) da Usenet na Internet.
ORBs (Object Request Brokers) o componente responsvel por atender requisies de

objetos em um framework de objetos. Principal compo-
nente da arquitetura CORBA, ele recebe requisies de
clientes e disponibiliza o acesso objetos previamente
publicados em um diretrio de objetos.

Padro aberto todo o padro tecnolgico estabelecido por rgos in-

ternacionais ou por consrcios de empresas do mercado
que desenvolvem especificaes que se encontram pu-
blicamente disponveis. O PC (computador pessoal) foi
lanado e desenvolvido com padro aberto. As espe-
cificaes da Internet e seu desenvolvimento tambm.
A grande maioria das linguagens de programao tam-
bm.
RFC - Request for Comments documento formal da IETF, resultante de modelos e re-
(Solicitao de Comentrios) vises de partes interessadas. A verso final do RFC
tornou-se um padro em que nem comentrios nem alte-
raes so permitidos. As alteraes podem ocorrer, po-
rm, por meio de RFCs subseqentes que substituem ou
elaboram em todas as partes dos RFCs anteriores. RFC
tambm a abreviao de Remote Function Call (chamada
funcional remota).
RPCs (Remote Procedure Calls) o nome dado ao ato de chamar ou executar um pro-
cedimento ou programa que no se encontra na mesma
mquina do programa chamador.
SOA - Service Oriented Ar- Arquitetura proposta para interoperabilidade de siste-

chitecture (Arquitetura Orien- mas por meio de conjunto de interfaces de servios fra-
tada a Servios) camente acoplados (loosely coupled), onde os servios no
necessitam de detalhes tcnicos da plataforma dos ou-
tros servios para a troca de informaes ser realizada.
SOAP - Simple Object Ac- descreve um modelo para o empacotamento de pergun-

cess Protocol (Protocolo Sim- tas e respostas XML.O envio de mensagens SOAP uti-
ples para Acesso a Objetos) lizado para permitir o intercmbio de uma variedade de
informaes XML. A norma de SOAP assume a tarefa de
transmitir pedidos e respostas sobre servios entre usu-
rios e fornecedores de servios.

Software Livre programa de computador disponvel atravs de seu

cdigo-fonte e com a permisso para qualquer um us-
lo, copi-lo e distribu-lo, seja na sua forma original ou
com modificaes, seja gratuitamente ou com custo. O
software livre necessariamente no proprietrio, mas
importante no confundir software livre com software gr-
tis.
UDDI - Universal Descrip- o repositrio no qual os desenvolvedores registram os

tion Discovery and Integration Web Services disponveis que permitem aos clientes a
(Descrio, Descoberta e Inte- descoberta e a utilizao dos servios alocados em Ex-
grao Universais) tranets e Intranets.
W3C - World Wide Web Con- associao de indstrias que visa promover padres
sortium (Consrcio da Rede para a evoluo da web e interoperabilidade entre pro-
Mundial Web) dutos para WWW produzindo softwares de especificao
e referncia.
Web Services Aplicao lgica, programvel que torna compatveis

entre si os mais diferentes aplicativos, independente-
mente do sistema operacional, permitindo a comunica-
o e intercmbio de dados entre diferentes redes.
WSDL - Web Services Defi- um formato XML para descrio de servios web e
nition Language (Linguagem suas informaes para acesso. Ela descreve as funcio-
para definio de Servios nalidades dos servios oferecidos pelo provedor de ser-
Web) vios, bem como sua localizao e forma de acesso.
WWW ou Web (World Wide rea da Internet que contm documentos em formato
Web) de hipermdia, uma combinao de hipertexto com mul-
timdia. Os documentos hipermdia da WWW so cha-
mados de pginas de Web e podem conter textos, ima-
gens e arquivos de udio e vdeo, alm de ligaes com
outros documentos na rede. A caracterstica multimdia
da Web, tornou-a a poro mais importante da Internet.

XML - eXtensible Markup Lan- maneira flexvel para criar formatos de informaes co-
guage (Linguagem Markup muns e compartilhar ambos os formatos e os dados na
Extensvel) World Wide Web, nas intranets e em qualquer lugar. O
XML extensvel porque, diferentemente do HTML, os
smbolos markup so ilimitados e se autodefinem.
XMPP - eXtensible Messaging Protocolo aberto, baseado em XML para mensagens em

and Presence Protocol (Pro- tempo real.
tocolo de Mensageria em
Tempo Real)
XSL - eXtensible Stylesheet linguagem de criao de planilhas que descreve como

Language um dado mandado por meio da web, usando o XML, e
apresentado ao usurio. O XSL uma linguagem para
formatar um documento XML.

Apndice F
O Ambiente LabCluster
O LabCluster o laboratrio da SLTI/MP que prov infra-estrutura tecnolgica

e computacional, baseada em computao distribuda e padres abertos de hard-
ware e software para os projetos internos ou em parceria com a Secretaria de Lo-
gstica e Tecnologia da Informao. O laboratrio um ambiente de testes, pros-
peco e anlise de tecnologias, em especial de Cluster e Grid".
Alguns exemplos de aes prticas da SLTI com a aplicao de tecnologias de

Cluster e Grid" neste laboratrio so:
Tamandu: projeto piloto de minerao da base de dados de compras go-

vernamentais. O processo de minerao de dados tem como principais ob-
jetivos descobrir relacionamentos, geralmente no triviais, entre dados ar-
mazenados, fornecer subsdios para que seja possvel realizar previso de
tendncias futuras com base nos registros acumulados, bem como estabele-
cer parmetros para anlise e auditoria das informaes coletadas.
Projeto Qualidade de Dados Sociais: foi realizada uma chamada pblica em

2005 e posteriormente uma aquisio de soluo baseada em tecnologia de
Cluster para tratamento de qualidade de dados, que busca identificar incon-
sistncias e fraudes no acervo de bases de dados sociais do governo. Foram
utilizadas as bases: SISOBI, SIM, GFIP, CADUNICO e do Censo Previden-
cirio. O acervo de dados tratado neste projeto da ordem de 300 milhes
de registros, com possibilidade de expanso para at 1 bilho de registros.

G UIA DE C LUSTER F.1 - H ISTRICO DO L AB C LUSTER
Projeto de Integrao, Inteligncia e Informao de Governo (I 3 Gov): hos-

pedagem do sistema desenvolvido para integrar e oferecer aos gestores do
governo federal uma viso voltada para o custeio da administrao pblica.
Foi desenvolvida uma arquitetura referencial de integrao de sistemas go-
vernamentais baseada em padres abertos e Web Services.
Guia de administrao de ambientes em Cluster e Grid" : este documento

possui um conjunto de justificativas para a adoo de tecnologias basea-
das em computao distribuda pelo governo brasileiro e uma abordagem
tcnica e gerencial das tecnologias de Cluster de Processamento de Alto De-
sempenho, Cluster de Aplicao, Cluster e replicao de Banco de Dados,
Cluster de Armazenamento, Grid de saco-de-tarefas, Virtualizao de re-
cursos computacionais.
Testes, anlises e prospeco tecnolgica: foram realizados testes, anlises e

prospeces tecnolgicas das tecnologias de Processamento de Alto Desem-
penho (MPI e PVM), Sistema de Arquivos Compartilhados (GFS, OCFS2,
OCFS), Cluster de Banco de Dados (Oracle RAC, Sequoia, PgCluster, Par-
gres), Cluster de Aplicao (Linux Virtual Server, HeartBeat, CARP), Virtu-
alizao de Recursos (VMware e Xen).
F.1 Histrico do LabCluster
O Departamento de Integrao de Sistemas de Informao (DSI), da Secretaria de

Logstica e Tecnologia de Informao possui como atribuio definir as regras e
padres de integrao do Governo Federal.
No Departamento so desenvolvidos projetos relacionados com a integrao dos

sistemas estruturadores do Governo Federal, integrao das bases de cadastros
sociais, definio de padres abertos para interoperabilidade1 , migrao para
software livre2 e inovaes tecnolgicas baseadas em tecnologias emergentes e
abertas.
Tais iniciativas objetivam a transparncia nas relaes tecnolgicas internas na

Administrao Pblica Federal, melhoria da qualidade do servio de Governo
1
E-Ping - Padres de Interoperabilidade de Governo Eletrnico.
2
Guia de Referncia de Migrao para software livre do Governo Federal

G UIA DE C LUSTER F.1 - H ISTRICO DO L AB C LUSTER
Eletrnico aos cidados, racionalizao do uso de recursos pblicos em tecnolo-

gia da informao, independncia tecnolgica e insero do uso de tecnologias
inovadoras no Governo Federal.
At 2004 a Secretaria no dispunha de um laboratrio para a implementao de

projetos piloto, provas de conceito e prospeco Tecnolgica. Esta carncia de
laboratrio muitas vezes dificultava a realizao dos projetos desenvolvidos pelo
Departamento de Integrao de Sistemas de Informao uma vez que o referido
Departamento via-se obrigado a depender de atores externos, que nem sempre
possuem a possibilidade de atender as demandas dentro do prazo exeqvel.
O primeiro laboratrio piloto foi implementado com estaes de trabalho do pr-

prio ministrio para atender a demanda de otimizao de compras governamen-
tais atravs do uso de tecnologia baseada em data minning para pesquisar os
melhores e piores padres de compra. O software utilizado neste projeto foi o
Tamandu3 um software de minerao de dados em Cluster desenvolvido pela
UFMG com recursos de financiamento do Governo Federal atravs da FINEP e
disponibilizado como software livre.
Este laboratrio piloto era composto por um conjunto de 8 mquinas desktop

interligadas em um switch 100Mbps dedicado de 12 portas e configuradas como
um Cluster de processamento baseado em tecnologia PVM4 .
Os resultados deste projeto foram muito proveitosos e a Secretaria resolveu in-

vestir na criao de um Laboratrio de Inovaes Tecnolgicas em Cluster e Grid,
para tanto foi realizada a aquisio de 32 servidores dual processados totalizando
uma capacidade de 64 processadores Xeon de 2.4Ghz, 80GB de memria ram e
7.36TB de armazenamento em disco rgido.
Este laboratrio foi denominado LabCluster por conta do projeto de inovaes

tecnolgicas em Cluster e Grid que busca construir alternativas economicamente
viveis, tecnologicamente sustentveis e inovadoras ao uso de computadores de
grande porte.
3
http://tamandua.speed.dcc.ufmg.br/
4
Parallel Virtual Machine - Mquina paralela virtual

G UIA DE C LUSTER F.2 - M ISSO DO L AB C LUSTER
F.2 Misso do LabCluster
A Misso do LabCluster prover infra-estrutura tecnolgica e computacional, ba-

seada em computao distribuda e padres abertos de hardware e software para
os Projetos internos ou em parceria com a Secretaria de Logstica e Tecnologia da
Informao.
O LabCluster um ambiente de testes, prospeco e anlise, onde so feitas pro-

vas de conceito, projetos piloto e no deve ser tratado como um ambiente de pro-
duo. Para a disponibilizao de aplicaes em produo dever ser utilizada a
infra-estrutura das empresas de TI do Governo Federal, tais como: DATAPREV e
SERPRO.
F.3 Descrio do Ambiente LabCluster
Em consonncia com as diretrizes de Governo Eletrnico de racionalizao de

recursos e utilizao de Software Livre:
Todo o hardware utilizado no laboratrio baseado em tecnologia i386 e

padres abertos.
Toda a infra-estrutura de software bsico5 do laboratrio em Software Li-

vre ou aberto, para no comprometer a adoo de tecnologias inovadoras
pelo governo com os custos de aquisio de licenas de software.
Excees:
Podero existir aplicaes especficas de projetos, que no sero Soft-

ware Livre ou aberto, mas a infra-estrutura de software base ser total-
mente livre ou aberta
5
Entende-se por software bsico, o sistema operacional e os softwares e aplicaes necessrios
para o funcionamento, administrao e gerenciamento do Cluster.

G UIA DE C LUSTER F.4 - I NFRA - ESTRUTURA DE H ARDWARE
F.4 Infra-estrutura de Hardware
A tabela F.1 apresenta resumidamente as configuraes dos hardwares dispon-

veis no LabCluster, enquanto as sees subseqentes apresentam o detalhamento
das configuraes disponveis:
Servidores SuperMicro 1U
Quant. CPU Memria HD Rede
16 02 x 2.4Ghz Xeon HT 02 GB 01 x IDE 80GB 02 x Gigabit
Servidores SuperMicro 2U
Servidor SuperMicro Gabinete
Desktops Novadata
12 01 x 2.4Ghz Pentium 256MB 01 x IDE 40GB 01 x
IV 100Mbps
Servidor Dell PowerEdge 1850
08 02 x 3.6Ghz 02 GB 01 x SCSI 73GB 02 x Gigabit
Tabela F.1: Tabela de Hardware
F.5 Poltica de Utilizao do Ambiente LabCluster
A Poltica de Utilizao do Ambiente LabCluster um documento criado dentro

da SLTI para conduzir e propiciar uma melhor relao de trabalho dos interessa-
dos com o laboratrio. Ele possui os seguintes objetivos:
Definir qual a misso do LabCluster,
Descrever os procedimentos de uso do ambiente LabCluster,
Especificar a Infra-estrutura fsica e lgica, de hardware e software do Lab-

Cluster,
Definir as polticas e normas de utilizao do LabCluster,

G UIA DE C LUSTER F.5 - P OLTICA DE U TILIZAO DO A MBIENTE L AB C LUSTER
Definir as polticas e normas do ambiente de produo do LabCluster.
Este documento pode ser obtido em: http://guialivre.governoeletronico.

gov.br/guiaonline/downloads/guias/politica.pdf

Apndice G
Outros Documentos Produzidos
Em paralelo ao trabalho neste Guia, vrios outros documentos foram trabalhados

pela equipe da SLTI, e podem ser obtidos no sitio do Guia de Cluster: http:
//guialivre.governoeletronico.gov.br/guiacluster/.
Os documentos se situam em vrios tpicos e necessidades sendo divididos da

seguinte forma:
Documentos internos:
Poltica de Utilizao do Ambiente LabCluster,

Minerao de Dados - Tamandu
Documentao de Tecnolgias; que vem sendo escritas de forma

colaborativa no wiki do seminrio de cluster e grid http:
//guialivre.governoeletronico.gov.br/mediawiki/index.php/
DocumentacaoTecnologias, como por exemplo:
DRBD v07 - Distributed Replicated Block Device,

DRBD v08 - OCFS2, LVS, Heartbeat e ldirector,
Virtualizao de Recursos - Xen,
Implementao de Firewall Redundante com OpenBSD, Packet Filter,
PFSYNC e CARP.
Tradues:

G UIA DE C LUSTER CAPTULO G : O UTROS D OCUMENTOS P RODUZIDOS
Guia do Usurio Sequoia,

Manual OpenMosix,
How-to PGcluster,

Referncias Bibliogrficas
[1] Advanced mysql replication techniques. http://www.onlamp.com/pub/

a/onlamp/2006/04/20/advanced-mysql-replication.html.
[2] Arquitetura e-ping. http://www.eping.e.gov.br.
[3] Blast webpage. http://www.ncbi.nlm.nih.giv/BLAST.
[4] Compute against the cancer site. http://www.computeagainstcancer.

org.
[5] The dzero experiment. http://www-d0.fnal.gov.
[6] Governo eletrnico - conhea o gov.br. http://www.governoeletronico.

gov.br.
[7] Introducing slony. http://www.onlamp.com/pub/a/onlamp/2004/11/

18/slony.html.
[8] Linux virtual server. http://www.linuxvirtualserver.org.
[9] Live backups of mysql using replication. http://www.onlamp.com/pub/

a/onlamp/2005/06/16/MySQLian.html.
[10] Lvs-mini-howto. http://www.austintek.com/LVS/LVS-HOWTO/

mini-HOWTO/.
[11] Modifying slony clusters. http://www.onlamp.com/pub/a/onlamp/

2005/03/17/slony_changes.html.
[12] Mygrid site. http://www.ourgrid.org/mygrid.
[13] Mysql - reference manual. http://dev.mysql.com/doc/refman/5.1/en/

index.html.

G UIA DE C LUSTER REFERNCIAS BIBLIOGRFICAS
[14] OMG - object management group. http://www.omg.org/corba.
[15] Pargres. http://pargres.nacad.ufrj.br.
[16] Pargres: uma camada de processamento paralelo de consultas sobre

o postgresql. http://pargres.nacad.ufrj.br/Documentos/id_9830_
wsl2005_pargres.pdf.
[17] Pgcluster. http://pgcluster.projects.postgresql.org/.
[18] Pgpool. http://pgpool.projects.postgresql.org/.
[19] Postgresql. http://www.postgresql.org.
[20] Replication in mysql. http://www.linux-mag.com/content/view/

1599/0/1/0/.
[21] RMI - remote method invocation specification. http://java.sun.com/

products/jdk/rmi/index.jsp.
[22] Seti@home site. http://setiathome.ssl.berkeley.edu.
[23] Simgrid site. http://gcl.ucsd.edu/simgrid.
[24] United devices site. http://www.ud.com.
[25] ISO New England: Electricity trading over the internet begins in six
new england states. Business Wire - http://industry.java.sun.com/
javanews/stories/story2/0,1072,15093,00.html, May 1999.
[26] The evolution of UDDI: UDDI.org white paper. http://www.uddi.org/

pubs/the_evolution_of_uddi_20020719.pdf, 2002.
[27] UDDI: Universal description, discovery and integration of web services.

http://www.uddi.org, 2002.
[28] Business process execution language for web services version 1.1.
http://www-128.ibm.com/developerworks/library/specification/
ws-bpel, May 2003.
[29] Seti@home client program remote buffer overflow vulnerability. http://

www.securityfocus.com/bid/7292/info/, April 2003.
[30] Entropia web page. http://www.entropia.com, 2004.

[31] Mygrid online manual. http://www.ourgrid.org, 2004.
[32] Gnutella. http://www.gnutella.com, 2005.
[33] Grid physics network. http://www.griphyn.org/, 2005.
[34] Growing animated film talent. http://www.hpl.hp.com/SE3D/

se3d-overview.html, 2005.
[35] Omgs corba website. http://www.corba.org/, 2005.
[36] Ourgrid project. http://www.ourgrid.org, 2005.
[37] SETI@home top users. http://setiathome2.ssl.berkeley.edu/

stats/users.html, March 2005.
[38] Teragrid. http://www.teragrid.org/, 2005.
[39] Web services activity. http://www.w3.org/2002/ws/, 2005.
[40] Ws - resource framework. http://www.globus.org/wsrf/, 2005.
[41] Josh Aas. Understanding the linux 2.6.8.1 cpu scheduler. http://josh.
trancesoftware.com/linux/linux_cpu_scheduler.pdf. Ultima Visita
em 20.09.2005 12:12.
[42] MySQL AB. Mysql manual. http://www.mysql.com/doc/en/index.

html. Ultima Visita em 20.09.2004 12:20.
[43] D. Abramson, J. Giddy, I. Foster, and L. Kotler. High performance para-

metric modeling with nimrod/G: Killer application for the global grid? In
IPDPS, pages 520528, 2000.
[44] A. Adya, W. J. Bolosky, M. Castro, G. Cermak, R. Chaiken, J. R. Douceur,

J. Howell, J. R. Lorch, M. Theimer, and R. P. Wattenhofer. FARSITE: Fede-
rated, available, and reliable storage for an incompletely trusted environ-
ment. In Proceedings of the 5th OSDI, December 2002.
[45] C. J. AGHA, G; CALLSEN. ActorSpace: An Open Distributed Programming

Paradigm. ACM SIGPLAN Symposium on Principles and Practice of Paral-
lel Programming, 1993.
[46] G. Agha. ACTORS: A Model of Concurrent Computation in Distributed Sys-

tems. Mit Press, 1986.

[47] G. Actors AGHA. MIT Press, Cambridge, MA. A Model of Concurrent Com-
putation in Distributed Systems, 1986.
[48] Marcos Aguilera, Ramaprabhu Janakiraman, and Lihao Xu. Using era-
sure codes efficiently for storage in a distributed system. In Proceedings
of the 2005 International Conference on Dependable Systems and Networks (DSN
2005), Yokohama, Japan, June-July 2005.
[49] Hassan AIT-KACI. The WAM: A (Real) Tutorial. Paris: Digital Equipment
Corporation, Research Laboratory, 1990.
[50] et. al. Al Geist. PVM: Parallel Virtual Machine: A Users; Guide and Tutorial for
Network Parallel Computing (Scientific and Engineering Computation). The Mit
Press, Cambridge, Massachussets.
[51] W. Allcock, J. Bester, J. Bresnahan, A. Chervenak, L. Liming, S. Meder, and

S. Tueck. Gridftp protocol specification. GGF GridFTP Working Group
Document, September 2002.
[52] W. Allcock, A. Chervenak, I. Foster, C. Kesselman, and C. Salisbury S. Tu-

ecke. The data grid: Towards an architecture for the distributed manage-
ment and analysis of large scientific datasets. Journal of Network and Compu-
ter Applications, 23:187-200, 2001.
[53] Globus Alliance. Ogsa site. http://www.globus.org/ogsa, 2003.
[54] S. F. Altschul, W. Gish, W. Miller, E. W. Myers, and D. J. Lipman. Basic local

alignment search tool. Journal of Molecular Biology, 1(215):403410, 1990.
[55] S. F. Altschul, T. L. Madden, A. A. Schaffer, J. Zhang, Z. Zhang, W. Mil-

ler, and D. J. Lipman. Gapped BLAST and PSIBLAST: a new generation
of protein database search programs. Nucleic Acids Research, 25:33893402,
1997.
[56] Ahmed Amer and Amr El-Kadi. Beating bottlenecks in the design of dis-
tributed file systems. Dez 1996.
[57] T. Bray and J. Paoli and C. M. Sperberg-McQueen. Extensible Markup Lan-

guage (XML) 1.0 (Second Edition). W3C, 1.1 edition, October 2000. http:
//www.w3c.org/TR/REC-xml.
[58] Carl Anderson and John J. Bartholdi III. Centralized versus decentralized
control in manufacturing: Lessons from social insects. In I. P. McCarthy

and T. Rakotobe-Joel, editors, Complexity and Complex Systems in Industry,

pages 92105, September 2000.
[59] D. Anderson, J. Cobb, and E. Korpela. SETI@home: An experiment in

public-resource computing. Communication of the ACM, 45 (11):5661, 2002.
[60] N. Andrade, F. Brasileiro, W. Cirne, and M. Mowbray. Discouraging free-

riding in a peer-to-peer grid. In HPDC13, the Thirteenth IEEE International
Symposium on High-Performance Distributed Computing, June 2004.
[61] N. Andrade, W. Cirne, F. Brasileiro, and P. Roisenberg. Ourgrid: An appro-

ach to easily assemble grids with equitable resource sharing. In Proceedings
of the 9th Workshop on Job Scheduling Strategies for Parallel Processing, 2003.
[62] Nazareno Andrade, Walfredo Cirne, Francisco Brasileiro, and Paulo Roi-
senberg. Ourgrid: An approach to easily assemble grids with equitable
resource sharing. 9th Workshop on Job Scheduling Strategies for Parallel Proces-
sing, June 2003.
[63] Gregory ANDREWS. Synchronizing resources. ACM Transactions on Pro-

gramming Languages and Systems, 3(4):405430, october 1981.
[64] Gregory ANDREWS. The distributed programming language sr - me-

chanisms, design and implementation. Software-Practice and Experience,
12(8):719753, august 1982.
[65] Gregory R. Andrews. Synchronising resources. ACM Transactions on Pro-

gramming Languages Andsystems, 3(4):405430, oct 1981.
[66] Ronald ANDREWS, Gregory.; OLSSON. The evolution of the sr language.

Distributed Computing, 1(3):133149, july 1986.
[67] Ronald ANDREWS, Gregory; OLSSON. An overview of the sr language

and implementation. CM Transactions on Programming Languages and Sys-
tems, 10(1):5186, january 1988.
[68] Ronald A. ANDREWS, Gregory R.; OLSSON. The SR Programming Lan-

guage. The Benjamin/Cummings Publishing Company, 1992.
[69] R. N. Anthony. Planing and control systems: A framework for analysis.

Technical report, Havard University, Graduate Schoole of Business Admi-
nistration, 1965.

[70] Eliane Arajo, Walfredo Cirne, Gustavo Wagner, and Nigini Oliveira. The
seghidro experience: Using the grid to empower a hydro meteorological
scientific network.
[71] Bradley BAKER, Louis; SMITH. Parallel Programming. McGraw-Hill, Inc,

1996.
[72] K. R. Baker. Requirements planning. In S.C. Graves, A.H.G. Rinnooy Kan,

and P.H. Zipkin, editors, Handbooks in Operations Research and Management
Science - Logistics of Production and Inventory, volume 4, chapter Chapter 11.
North-Holland, 1993.
[73] Mark Baker, Rajkumar Buyya, and Domenico Laforenza. The Grid: Inter-
national efforts in Grid Computing, 2000.
[74] Jennifer G. BAL, Henri E.; STEINER. Programming languages for distribu-
ted computing systems. ACM Computing Surveys, 21(3):261322, september
1989.
[75] F. Banaei-Kashani, C. Chen, and C. Shahabi. Wspds: Web services peer-to-

peer discovery dervice. In Proc. of International Symposium on Web Services
and Applications (ISWS04), 2004.
[76] A. Baratloo, P. Dasgupta, V. Karamcheti, and Zvi M. Kedem. Metacompu-

ting with MILAN. In Heterogeneous Computing Workshop, pages 169183,
1999.
[77] A. Baratloo, P. Dasgupta, and Z. M. Kedem. CALYPSO: A novel software

system for fault-tolerant parallel processing on distributed platforms. In
Proc. of the Fourth IEEE International Symp. on High Performance Distributed
Computing (HPDC-4), pages 122129, 1995.
[78] A. Baratloo, M. Karaul, Z. M. Kedem, and P. Wyckoff. Charlotte: Metacom-

puting on the web. In Proc. of the 9th International Conference on Parallel and
Distributed Computing Systems (PDCS-96), 1996.
[79] A. C. Barbosa, J. Sauv, W. Cirne, and M. Carelli. Independently auditing

service level agreements in the grid. In Proceedings of the 11th HP OpenView
University Association Workshop (HPOVUA 2004), 2004.
[80] Jorge L. V BARBOSA. Princpios do Holoparadigma. CPGCC da UFRGS, 1999.

[81] P. Barham, B. Dragovic, K. Fraser, S. Hand, T. Harris, A. Ho, R. Neugebar,

I. Pratt, and A. Warfield. Xen and the art of virtualization. In Proceedings of
the ACM Symposium on Operating Systems Principles (SOSP), October 2003.
[82] Alexander Barmouta and Rajkumar Buyya. GridBank: A Grid Accounting

Services Architecture (GASA) for distributed systems sharing and integra-
tion, 2003 (submitted).
[83] J. Bartholdi and D. Eisenstein. Bucket brigades. http://www.

isye.gatech.edu/people/faculty/John_Bartholdi/bucket\
discretionary{-}{}{}brigades.html, 2002.
[84] J. Basney, M. Livny, and P. Mazzanti. Harnessing the capacity of compu-

tational grids for high energy physics. In Conference on Computing in High
Energy and Nuclear Physics, 2000.
[85] Jim Basney and Miron Livny. Deploying a High Throughput Computing Clus-
ter, volume 1, chapter High Performance Cluster Computing. Prentice Hall,
may 1999.
[86] O. Beaumont, L. Carter, J. Ferrante, and Y. Robert. Bandwidth-centric allo-

cation of independent task on heterogeneous plataforms. In Proceedings of
the Internetional Parallel and Distributed Processing Symposium, Fort Lauder-
dale, Florida, April 2002.
[87] K. Beck. Extreme Programming Explained: Embrace Change. Addison-Wesley,

1999.
[88] F. Berman, A. Hey, and G. Fox, editors. Grid Computing - Making the Global
Infrastructure a Reality. John Wiley and Sons, Ltd, 2003.
[89] F. D. Berman, R. Wolski, S. Figueira, J. Schopf, and G. Shao. Application-

level scheduling on distributed heterogeneous networks. In Proceedings of
Supercomputing96, 1996.
[90] Francine Berman and Richard Wolski. Scheduling from the perspective of
the application. In HPDC, pages 100111, 1996.
[91] H. Berman, J. Westbrook, Z. Feng, G. Gilliland, T. Bhat, H. Weissig,

I. Shindyalov, and P. Bourne. The protein data bank. Nucleic Acids Rese-
arch, 28:235242, 2000.

[92] J. Bester, I. Foster, C. Kesselman, J. Tedesco, and S. Tuecke. Gass: A data

movement and access service for wide area computing systems. In Sixth
Workshop on I/O in Parallel and Distributed Systems, May 1999.
[93] Ranjita Bhagwan, Stefan Savage, and Geoffrey M. Voelker. Understanding

availability. In Proceedings of the 2nd International Workshop on Peer-to-Peer
Systems, 2003.
[94] W. J. Bolosky, J. R. Douceur, D. Ely, and M. Theimer. Feasibility of a ser-

verless distributed file system deployed on an existing set of desktop pcs.
In Proceedings of the International Conference on Measurement and Modeling of
Computer Systems, pages 3443, 2000.
[95] G. Booch. Object Oriented Design. The Benjamin/Cummings Publishing

Company, Inc, 1st edition, 1991.
[96] M. BRIAT, J.; FAVRE. . In Computer Science, editor, Parallel Architectures and
Languages Europe, volume 506, chapter Scheduling of OR-parallel Prolog
on a scalable reconfigurable distributed memory multiprocessor. Springer-
Verlang, 1991.
[97] Rachid BRIOT, Jean-Pierre; GUERRAOUI. Concurrency and distribution

in object-oriented programming. ACM Computing Surveys, 30(3):291329,
september 1998.
[98] R. Buyya, D. Abramson, and J. Giddy. An economy driven resource mana-

gement architecture for computational power grids. In International Confe-
rence on Parallel and Distributed Processing Techniques and Applications, 2000.
[99] R. Buyya, D. Abramson, and J. Giddy. A case for economy grid architecture
for service-oriented grid computing. In 10th IEEE International Heterogene-
ous Computing Workshop (HCW 2001), 2001.
[100] R. Buyya, D. Abramson, J. Giddy, and H. Stockinger. Economic models

for resource management and scheduling in grid computing. The Journal of
Concurrency and Computation: Practice and Experience (CCPE), Maio 2002.
[101] Rajkumar. BUYYA. High Performance Cluster Computing, Architectures

and Systems. Prentice Hall, 1999.
[102] Rajkumar Buyya, David Abramson, and Jonathan Giddy. Nimrod/g: An

architecture of a resource management and scheduling system in a global

computational grid. In The 4th International Conference on High Performance

Computing in Asia-Pacific Region (HPC Asia 2000), Beijing, China, 2000.
[103] Rajkumar Buyya and Sudharshan Vazhkudai. Compute Power Market:

Towards a Market-Oriented Grid. In The First IEEE/ACM International Sym-
posium on Cluster Computing and the Grid (CCGrid 2001), Beijing, China, 2000.
IEEE Computer Society Press.
[104] Toni BUYYA, Rajkumar; CORTES. Single system image, special issue. In
Sage Science Press, editor, International Journal of High Performance, volume
Volume 15, chapter Pages: 124, 135. Sage Science Press, 2001.
[105] Philip H. Carns, Walter B. Ligon III, Robert B. Ross, and Rajeev Tha-
kur. Pvfs: A parallel virtual file system for linux clusters. http://
www.parl.clemson.edu/pvfs/el2000/extreme2000.ps. Ultima Visita
em 20.09.2005 12:12.
[106] David CARRIERO, Nicholas; GELERNTER. Data paralelismo and linda.

Technical report, International Workshop on Languages and Compilers for
Parallel Computing, 1992.
[107] N. Carriero and D. Gelernter. How to write parallel programs: a guide to

the perplexed. Communications of the ACM, 21, 1989.
[108] H. Casanova. Simgrid: A toolkit for the simulation of application schedu-

ling. In Proceedings of the First IEEE/ACM International Symposium on Cluster
Computing and the Grid, Brisbane Australia, May 2001.
[109] H. Casanova and F. Berman. Grid Computing: making the Global Infrastructure
a Reality, chapter Parameter Sweep on the Grid with APST. John Wiley and
Sons, 2003.
[110] H. Casanova, J. Hayes, and Y. Yang. Algorithms and software to sche-

dule and deploy independent tasks in grid environments. In Proceedings
of Workshop on Distributed Computing/Metacomputing and Resource Globaliza-
tion, 2002.
[111] H. Casanova, A. Legrand, D. Zagorodnov, and F. Berman. Heuristics for

scheduling parameter sweep applications in grid environments. In Procee-
dings of the 9th Heterogeneous Computing Workshop, pages 349363, Cancun,
Mexico, May 2000. IEEE Computer Society Press.

[112] H. Casanova and L. Marchal. A network model for simulation of grid ap-
plication. Research Report N o 2002-40, October 2002.
[113] Henri Casanova, Graziano Obertelli, Francine Berman, and Rich wolski.
The apples parameter sweep template: User-level middleware for the grid.
In Supercomputing Conference (SC2000), 2000.
[114] A. Chien, B. Calder, S. Elbert, and K. Bhatia. Entropia: architecture and per-
formance of an enterprise desktop grid system. Journal of Parallel Distributed
Computing, 63:597610, 2003.
[115] W. Cirne. Grids computacionais: Arquiteturas, tecnologias e aplicaes. In

Anais do Terceiro Workshop em Sistemas Computacionais de Alto Desempenho,
Vitria, Esprito Santo, Brasil, October 2002.
[116] W. Cirne and F. Berman. Using moldability to improve the performance of

supercomputer jobs. Parallel and Distributed Computing, 62(10):15711601,
2002.
[117] W. Cirne, F. Brasileiro, L. Costa, D. Paranhos, E. Santos-Neto, N. Andrade,

C. De Rose, T. Ferreto, M. Mowbray, R. Scheer, and J. Jornada. Scheduling
in bag-of-task grids: The pau case. In Proceedings of the 16th Symposium
on Computer Architecture and High Performance Computing (SBAC-PAD2004),
October 2004.
[118] W. Cirne and K. Marzullo. The computational coop: Gathering clusters into
a metacomputer. In PPS/SPDP99 Symposium, 1999.
[119] W. Cirne and K. Marzullo. Open Grid: A user-centric approach for grid
computing. In Proceedings of the 13th Symposium on Computer Architecture
and High Performance Computing, 2001.
[120] W. Cirne, D. Paranhos, L. Costa, E. Santos-Neto, F. Brasileiro, J. Sauv, F. Al-

ves B. da Silva, C. O. Barros, and C. Silveira. Running bag-of-tasks appli-
cations on computational grids: The mygrid approach. In Proceedings of the
ICCP2003 - International Conference on Parallel Processing, October 2003.
[121] L. et al Clarke. The mpi message passing interface standard. Technical

report, Knoxville: University of Tenessee, 1994.
[122] Inc. Cluster Resources. Maui cluster scheduler. http://www.

clusterresources.com/pages/products/maui-cluster-scheduler.
php. Ultima Visita em 20.04.2006 12:20.

[123] Inc. Cluster Resources. Torque overview. http:

//www.clusterresources.com/pages/products/
torque-resource-manager.php. Ultima Visita em 20.04.2006 12:20.
[124] Bram Cohen. Incentives build robustness in bittorrent. http://www.

bittorrent.com/bittorrentecon.pdf, 2004.
[125] M. C. Coint. El Manual para el Clustering con OpenMosix. miKeL a.k.a.mc2,

GNU Free Documentation Licence, 2004.
[126] P. W. A. Costa. Como surgiram os data warehouses? Computerworld, no-

vembro:16, 1997.
[127] F. P. Coyle. Web Services, and the Data Revolution. Addison-Wesley Informa-
tion Technology Series, 2002.
[128] D. E. CULLER and J.P. SINGH. Parallel Computer Architecture: a hardware

and software approach. Morgan Kaufmann, 1999.
[129] David et al. CULLER. LogP: Toward a Realistic Model of Parallel Computation.
ACM SIGPLAN Symposium on Principles and Pratice of Parallel Program-
ming, 1993.
[130] f. Culler. Parallel Computer Architecture: A Hardware/Software Approach. Mor-

gan Kaufmann, San Francisco, CA, 1998.
[131] F. Curbera, Y. Goland, J. Klein, F. Leymann, D. Roller, S. Thatte, and S. We-

erawarana. Business process execution language for web services, version
1.0. Standards propsal by BEA Systems, International Business Machines
Corporation, and Microsoft Corporation, 2002.
[132] K. Czajkowski, D. Ferguson, I. Foster, J. Frey, S. Graham, T. Maquire,

D. Snelling, and S. Tuecke. From open grid services infrastructure to ws-
resource framework: Refactoring & evolution. Global Grid Forum Draft
Recommendation, May 2004.
[133] K. Czajkowski, I. Foster, N. Karonis, C. Kesselman, S. Martin, W. Smith,

and S. Tuecke. A resource management architecture for metacomputing
systems. In IPPS/SPDP98 Workshop on Job Scheduling Strategies for Parallel
Processing, pages 6282, 1998.
[134] Gustavo da Gama Torres. A empresa pblica de informtica e informao:

Modelo de gesto e papel. Revista IP, 2(1), Maio 2000.

[135] Programa Sociedade da Informao (SocInfo). Sociedade da informao

no brasil - livro verde. http://ftp.mct.gov.br/Livro_Verde/Default3.htm.
Ultima Visita em 11.09.2006 12:20.
[136] Mario Dantas. Computao Distribuda de Alto Desempenho. Axcel Books,

2005.
[137] Daniel Darlen. Utilizao de ferramenta de minerao de dados em ambi-

ente cluster. http://guialivre.governoeletronico.gov.br/labcluster/
tamandua.pdf. ltima Visita em 11.09.2006 12:20.
[138] C. J. Date. An Introduction to Database Systems. Addison-Wesley, Reading,

MA, 6 edition, 1995.
[139] T. Davis, A. Chalmers, and H. W. Jensen. Practical parallel processing for

realistic rendering. In ACM SIGGRAPH, 2000.
[140] Escola Regional de Alto Desempenho. Caderno dos Cursos Permanente. Co-
misso Regional de Alto Desempenho - Regional do Rio Grande do Sul,
Sociedade brasileira de Computao, 2006.
[141] Escola Regional de Alto Desenpenho. Primeira Escola Regional de Alto Desem-
penho. Comisso Regional de Alto Desempenho - Regional do Rio Grande
do Sul, Sociedade brasileira de Computao, 2001.
[142] Escola Regional de Alto Desenpenho. Segunda Escola Regional de Alto De-
sempenho - So Leopoldo - RS. Comisso Regional de Alto Desempenho -
Regional do Rio Grande do Sul, Sociedade brasileira de Computao, 2002.
[143] Escola Regional de Alto Desenpenho. Terceira Escola Regional de Alto De-
sempenho - Santa Maria - RS. Comisso Regional de Alto Desempenho -
Regional do Rio Grande do Sul, Sociedade brasileira de Computao, 2003.
[144] Escola Regional de Alto Desenpenho. Quarta Escola Regional de Alto Desem-
penho - Pelotas -RS. Comisso Regional de Alto Desempenho - Regional do
Rio Grande do Sul, Sociedade brasileira de Computao, 2004.
[145] Escola Regional de Alto Desenpenho. Quinta Escola Regional de Alto Desem-
penho - Canoas - RS. Comisso Regional de Alto Desempenho - Regional do
Rio Grande do Sul, Sociedade brasileira de Computao, 2005.

[146] Escola Regional de Alto Desenpenho. Sexta Escola Regional de Alto Desempe-
nho - Iju - RS. Comisso Regional de Alto Desempenho - Regional do Rio
Grande do Sul, Sociedade brasileira de Computao, 2006.
[147] C. DE ROSE, BLANCO, F. MAILLARD, N. SAIKOSKI, K. NOVAES, R. RI-

CHARD, and O. RICHARD. The virtual cluster: a dynamic environment
for exploitation of idle network resources. 14th symposium on Computer
Architecture and High-Performance Computing (SBAC-PAD 2002). USA: IEEE
Computer Society, pages p.141 148, 2002.
[148] Doug DEGROOT. Restricted and-parallelism. Technical report, INTER-

NATIONAL CONFERENCE ON FIFTH GENERATION COMPUTER SYS-
TEMS, 1984.
[149] Jay L. Devore. Probability and Statistics for Engineering and The Sciences, vo-
lume 1. John Wiley and Sons, Inc., 2000.
[150] Peter Dibble, Michael Scott, and Carla Ellis. Bridge: A high-performance
file system for parallel processors. http://www.cs.rochester.edu/u/
scott/papers/1988_ICDCS_Bridge.pdf. Ultima Visita em 20.12.2005
12:12.
[151] Ministrio do Planejamento. Guia livre - referncia de migrao para soft-

ware livre do governo federal. http://www.governoeletronico.gov.br. Ul-
tima Visita em 11.09.2006 12:20.
[152] Ministrio do Planejamento. Poltica de utilizao do labcluster.

http://guialivre.governoeletronico.gov.br/labcluster/
politica.pdf. ltima Visita em 11.09.2006 12:20.
[153] A. Downey. Predicting queue times on space-sharing parallel computers.

In Proceedings of 11th International Parallel Processing Symposium (IPPS97),
April 1997.
[154] R. Dragan. The meaning of moores law. PC Magazine Online, Online on Fe-
bruary 14th 2003. http://www.pcmag.com/article2/0,4149,4092,00.
asp.
[155] DRBD. Drbd. http://www.drbd.org. Ultima Visita em 20.04.2005 12:20.
[156] R. Durbin, S. Eddy, A. Krogh, and Graeme Mitchison. Biological Sequence

Analysis: Probabilistic Models of Proteins and Nucleic Acids. Cambridge Uni-
versity Press, 1998.

[157] Andrea C. Dusseau, David E. Culler, Klaus E. Schauser, and Richard P. Mar-
tin. Fast parallel sorting under logp: Experience with the cm-5. IEEE Tran-
sactions on Parallel and Distributed Systems, 7(8):791805, 1996.
[158] Csar A. F. De Rose e Philippe O. A. Navaux. Arquiteturas Paralelas. Insti-

tuto de Informtica da UFRGS, srie livros didticos - nmero 15 edition.
[159] Renato Silveira Eduardo Rodrigues Cerejo, Fabrcio Correia Sales. Exemplo
de arquitetura mimd - clusters. Technical report, Projeto final de curso do
INSTITUTO DE CINCIAS MATEMTICAS E DE COMPUTAO - USP,
2005.
[160] M. Eisler. Nfs version 2 and version 3 security issues and the nfs proto-
cols use of rpcsec gss and kerberos v5. http://rfc-ref.org/RFC-TEXTS/
2623/chapter2.html. Ultima Visita em 20.12.2005 12:12.
[161] Ted. EL-REWINI, Hesham; LEWIS. Distributed and Parallel Computing. Man-
ning Publications Co, 1998.
[162] W. R. Elwasif, J. S. Plank, and R. Wolski. Data staging effects in wide area
task farming applications. In IEEE Internetional Sysmposium on Cluster Com-
puting and the Grid, Brisbane, Australia, May 2001. IEEE Computer Society
Press.
[163] enbd. Ultima Visita em 20.04.2005 12:20.
[164] D. H. J. Epema, M. Livny, R. van Dantzig, X. Evers, and J. Pruyne. A

worldwide flock of Condors: load sharing among workstation clusters.
Journal on Future Generations of Computer Systems, 12(1), 1996.
[165] D.H.J. Epema, M. Livny, R. van Dantzig, X. Evers, and J. Pruyne. A

worldwide flock of Condors: Load sharing among workstation clusters.
Future Generation Computer Systems, 12:5365, 1996.
[166] Geist et al. PVM: Parallel Virtual Machine, A Users Guide and Tutorial for
Networked Parallel Computing. MIT Press, 1994.
[167] Huican Zhu et al. Adaptive load sharing for clustered digital library ser-
vers. In Proceedings of 7th IEEE International Symposium on High Performance
Distributed Computing, July 1998.
[168] W. Andrews et al. Predicts 2005: The impact of web services still grows. In
Gartner Research Note (G00123895), November 2004.

[169] ExeCRabLE. Prozessor history. http://www.execrable.de/hardware/

history.html. Ultima Visita em 20.09.2005 12:12.
[170] M. Faerman, R. Wolski A. Su, and Francine Berman. Adaptive performance

prediction for distributed data-intensive applications. In Proceedings of the
ACM/IEEE SC99 Conference on High Performance Networking and Computing,
Portland, OH, USA, 1999. ACM Press.
[171] FarSite. http://research.microsoft.com/sn/Farsite, 2005.
[172] D. Feitelson and L. Rudolph. Metrics and benchmarking for parallel job
scheduling. In Dror Feitelson and Larry Rudolph, editors, Job Scheduling
Strategies for Parallel Processing, volume 1459, pages 124. Lecture Notes in
Computer Science, Springer-Verlag, 1998.
[173] D. G. Feitelson. Metric and workload effects on computer systems evalua-

tion. Computer, 36(9):1825, September 2003.
[174] Dror Feitelson. Parallel workload archive.
[175] Ciro Campos Christo Fernandes. A reforma administrativa no brasil: oito

anos de implementao do plano diretor - 1995-2002, Out 2002.
[176] A. B. H. Ferreira. Novo Dicionrio Aurrio da Lngua Portuguesa. Editora

Nova Fronteira, 1986.
[177] K.W. Flynn, M.J. e Rudd. Parallel architectures. ACM Computing Surveys,
28(1):6770, 1996.
[178] Message Passing Interface Forum. MPI: A Message Passing Interface standard.
Message Passing Interface Forum, 1997.
[179] I. Foster. Designing and building parallel programs: Concepts and tools for paral-
lel software engineering. Addison-Wesley, 1995.
[180] I. Foster. What is the grid? a three point checklist. GRID today, 1(6), July
2002.
[181] I. Foster and C. Kesselman. Globus: A metacomputing infrastructure tool-

kit. International Journal of Supercomputer Applications, 11(2):115128, 1997.
[182] I. Foster and C. Kesselman. The globus project: A status report. In Procee-
dings of IPPS/SPDP Heterogeneous Computing Workshop, pages 418, 1998.

[183] I. Foster and C. Kesselman, editors. The Grid: Blueprint for a Future Compu-
ting Infrastructure. Morgan-Kaufmann, 1999.
[184] I. Foster, C. Kesselman, J. Nick, and S. Tuecke. The Physiology of the Grid:
An Open Grid Services Architecture for distributed systems integration.
Global Grid Forum - GGF, 2002.
[185] I. Foster, C. Kesselman, and S. Tuecke. The nexus approach to integrating

multithreading and communication. Journal of Parallel and Distributed Com-
puting, 37:7082, 1996.
[186] I. Foster, C. Kesselman, and S. Tuecke. The anatomy of the Grid: Enabling
scalable virtual organizations. International J. Supercomputer Applications,
15(3), 2001.
[187] The Apache Software Foundation. Apache jakarta tomcat. http://

tomcat.apache.org/tomcat-5.0-doc. Ultima Visita em 20.01.2006 12:20.
[188] The Apache Software Foundation. Apache tomcat. http://tomcat.

apache.org/. Ultima Visita em 20.01.2006 12:20.
[189] P. Francis, S. Jamin, V. Paxson, L. Zhang, D. F. Gryniewicz, and Y. Jim. An

architecture for a global internet host distance estimation service. In Proce-
edings of IEEE INFOCOM, 1999.
[190] FRESCO. Foundation for research on service composition. http://www.

servicecomposition.org/, 2005.
[191] J. Frey, T. Tannenbaum, M. Livny, I. Foster, and S. Tuecke. Condor-g: a com-

putation management agent for multi-institutional grids. In High Perfor-
mance Distributed Computing, 2001. Proceedings. 10th IEEE International Sym-
posium, pages 55 63, San Francisco, CA, USA, August 2001. IEEE Compu-
ter Society Press.
[192] Doreen L. Galli. Distributed Operating Systems. Prentice Hall, 2000.
[193] E. Gamma, R. Helm, R. Johnson, and J. Vlissides. Design Patterns. Addison-

Wesley Pub Co., 1995.
[194] Elizabeth Garbett, Andrew Scheferman, and Albert Tse. Virtual disk - its
not just for mainframes anymore. http://www.storagetek.com/. Ultima
Visita em 20.09.2005 12:12.

[195] Cludio F.R GEYER. Une contribution a letude du parallelisme ou en pro-

log sur des machines sans mmoire commune. Technical report, Grenoble:
Universit Joseph Fourier, 1991.
[196] GGF. Global grid forum. http://www.ggf.org, November 2003.
[197] Sanjay Ghemawat, Howard Gobio, and Shun-Tak Leung. The go-
ogle file system. http://www.cs.rochester.edu/sosp2003/papers/
p125-ghemawat.pdf. Ultima Visita em 20.09.2005 12:12.
[198] R. Gibbons. A historical application profiler for use by parallel schedulers.

Lecture Notes in Computer Science, 1291:5877, 1997.
[199] Dan Gisolfi. Is web services the reincarnation of CORBA? http://

www-106.ibm.com/developerworks/webservices/library/ws-arc3/.
[200] J. et al GOGUEN. An Introduction to OBJ3. Springer-Verlag, 1995.
[201] TI & Governo. O serpro inicia os testes para aban-

donar o mainframe e busca solues em software livre.
http://www.serpro.gov.br/noticiasSERPRO/
20060829_02/. TI & Governo, no 170, 29 de agosto de 2006.
[202] Grid3. Grid3: An application grid laboratory for science. http://www.

ivdgl.org/grid2003/, 2005.
[203] Gridbus. The gridbus project. http://www.gridbus.org/, 2005.
[204] Andrew S. Grimshaw, Wm. A. Wulf, and The Legion Team. The legion vi-
sion of a worldwide virtual computer. Communications of the ACM, 40(1):39
45, 1997.
[205] W. Lusk Gropp. Using MPI: Portable Parallel Programming with the Message
Passing-Interface. MIT Press, 1994.
[206] Apache Group. The apache xml project. http://xml.apache.org. Ultima

Visita em 20.01.2005 12:20.
[207] GriPhyN Group. http://www.GriPhyN.org, 2002.
[208] JBoss Group. Jboss group :: Professional open source. http://www.jboss.

org. Ultima Visita em 20.09.2004 12:20.

[209] Ibrahim F. Haddad. Pvfs: A parallel virtual file system for linux clus-
ters. http://www.linuxjournal.com/article/4354. Ultima Visita em
20.09.2005 12:12.
[210] Michael HANUS. The integration of functions into logic programming

from theory to practice. Journal of Logic Programming, 19/20(1):583628,
may/july 1994.
[211] S. Hastings, T. Kurc, S. Lamgella, U. Catalyurek, T. Pan, and J. Saltz. Image

processing for the grid: A toolkit for building gird-enabled image proces-
sing applications. In 3rd IEEE/ACM Internetional Symposium on Cluster Com-
puting and the Grid, 2003.
[212] A. Hefez. Curso de lgebra, volume 1. IMPA, 1993.
[213] F HERMENEGILDO, M.; ROSSI. Prolog and its Performance: Exploiting Inde-
pendente And-Parallelism. MIT Press, 1990.
[214] hilip H. Carns, Robert B. Ross, Walter B. Ligon III, and Pete Wycko. Bmi:
A network abstraction layer for parallel i/o. http://www.osc.edu/~pw/
papers/carns-bmi-ipdps05.pdf. Ultima Visita em 20.12.2005 12:12.
[215] Karen Epper Hoffman. Ending the grid lock. http://www.

technologyreview.com/, March 2005.
[216] T. Hogg and B. A. Huberman. Controlling chaos in distributed systems.

IEEE Transactions on Systems, Man and Cybernectics, 21:13251332, 1991.
[217] John H. Howard, Michael L. Kazar, Sherri G. Menees, David A. Nichols,

M. Satyanarayanan, Robert N. Sidebotham, and Michael J. West. Scale and
performance in a distributed file system. http://www.cs.cmu.edu/afs/
cs/project/coda/Web/docdir/s11.pdf. Ultima Visita em 20.09.2005
12:12.
[218] HPF. High performance fortran. http://www.crpc.rice.edu/HPFF/

home.html, December 2003.
[219] J. HUDAK, P.; FASEL. A Gentle Introduction to Haskell. ACM SIGPLAN

Notices, 1992.
[220] M. Humphrey, G. Wasson, M. Morgan, and N. Beekwilder. An early evalu-

ation of wsrf and ws-notification via wsrf.net. In Proc. of the 5th IEEE/ACM
International Workshop on Grid Computing, 2004.

[221] k. Hwang. Advanced computer architecture: parallelism, scalability, programma-

bility. Mcgraw-hill, New York, NY, 1993.
[222] Kai HWANG. Advanced Computer Architecture: Parallelism, Scalability, Pro-

grammability. McGraw-Hill, Inc, 1993.
[223] Miguel Cataln i Cort. El Manual para el Clustering con OpenMosix. TLDP,
2004.
[224] Adriana Iamnitchi and Ian Foster. A peer-to-peer approach to resource lo-
cation in grid environments. Grid Resource Management, 2003.
[225] Adriana Iamnitchi, Matei Ripeanu, and Ian Foster. Small-world file-sharing
communities, March 2004.
[226] Oscar H. Ibarra and Chul E. Kim. Heuristic algorithms for scheduling in-
dependent tasks on nonidentical processors. Journal of the ACM (JACM),
24(2):280289, 1977.
[227] IBM. System management guide: Communications and networks.

http://publib16.boulder.ibm.com/pseries/en_US/aixbman/
commadmn/nfs_netlock.htm. Ultima Visita em 20.09.2005 12:12.
[228] IEC. International electrotechnical commission. http://www.iec.ch/. Ul-

tima Visita em 20.04.2005 12:20.
[229] Virglio Jos Martins IGNACIO, Anbal Alberto Vilcapona y FERREIRA FI-
LHO. Mpi: uma ferramenta para implementao paralela. Pesquisa Opera-
cional, 22(1):105116, junho 2002.
[230] Red Hat Inc. Gfs. http://www.redhat.com. Ultima Visita em 20.04.2005

12:20.
[231] Sun Microsystems Inc. Rpc: Remote procedure call protocol specification
version 2. http://rfc-ref.org/RFC-TEXTS/1057/. Ultima Visita em
20.09.2005 12:12.
[232] Tech Insider. An interactive look at how ethernet has evolved. http://
www.networkworld.com/techinsider/2002/1014ethernettime.html.
[233] ISO. International organization for standardization. http://www.iso.org.


[234] Lauro Ivo. Grid scheduling: Adapting space-shared resources to eager

schedulers. In HP-OurGrid-Technical Report, 2004.
[235] B. Kemme J. M. Milan-Franco. Adaptative middleware for data replication.
[236] R. Jain. The Art of computer systems performance analysis: techniques for expe-
rimental design, measurement, simulation and modeling, volume 1. John Wiley
and Sons, Inc., 1991.
[237] M.-C. Jih, Li-Chi Feng, and Ruei-Chuan Chang. The design and implemen-
tation of the pasda parallel file system. In International Conference on Parallel
and Distributed Systems, chapter pages 142 - 147. 1994.
[238] Paul JONES, Mark P.; HUDAK. Implicit and explicit parallel program-
ming in haskell. nebula.systemsz.cs.yale.edu/pub/yale-fp/reports/RR-
982.ps.Z. julho de 1999.
[239] T. Jones, A. Koniges, and R. K. Yates. Performance of the ibm gene-

ral parallel file system. http://www.llnl.gov/icc/lc/siop/papers/
GPFSperformance.doc. Ultima Visita em 20.09.2005 12:12.
[240] Zhiwei Xu K. Hwang. Scalable Parallel Computing. McGraw-Hill, 2000.
[241] Poul-Henning Kamp and Robert N. M. Watson. Jails: Confining the om-
nipotent root. In Proceedings of 2nd International System Administration and
Networking Conference, May 2000.
[242] Subramanian Kannan, Mark Roberts, Peter Mayes, Dave Brelsford, and Jo-
seph F Skovira. Workload management with loadleveler. http://www.
redbooks.ibm.com/redbooks, November 2001.
[243] Z. M. Kedem, K. V. Palem, and P. G. Spirakis. Efficient robust parallel com-

putations (extended abstract). In ACM Symposium on Theory of Computing,
pages 138148, 1990.
[244] Philippe KERGOMMEAUX, Jacques Chassin; CODOGNET. Parallel logic

programming systems. ACM Computing Surveys, 26(3):295336, september
1994.
[245] Fabio Kon. Distributed file systems past, present and future a distributed
file system for 2006. http://choices.cs.uiuc.edu/~f-kon/DFSPaper.
ps.gz. Ultima Visita em 20.09.2005 12:12.

[246] Fabio Kon. Sistemas de arquivos distribudos. http://choices.cs.uiuc.

edu/~f-kon/thesis/kon-master.ps.gz. Ultima Visita em 20.09.2005
12:12.
[247] Charles M. Kozierok. Hard disk drives. http://www.pcguide.com/ref/

hdd/. Ultima Visita em 20.09.2005 12:12.
[248] Charles M. Kozierok. The processor. http://www.pcguide.com/ref/

cpu/. Ultima Visita em 20.09.2005 12:12.
[249] B. Kreaseck, L. Carter, H. Casanova, and J. Ferrant. Autonomous proto-

cols for bandwidth-centric scheduling of independent-task applications. In
17th International Parallel and Distributed Processing Symposium, Nice, France,
April 2003.
[250] Heather Kreger. Web services conceptual architrecture. http://www-3.

ibm.com/software/solutions/webservices/pdf/WSCA.pdf, 2003.
[251] J. Kubiatowicz, D. Bindel, Y. Chen, S. Czerwinski, P. Eaton, D. Geels,

R. Gummadi, S. Rhea, H. Weatherspoon, W. Weimer, C. Wells, and B. Zhao.
Oceanstore: An architecture for global-scale persistent storage. In Proce-
edings of the Ninth International Conference on Architectural Support for Pro-
gramming Languages and Operating Systems. IEEE Computer Society Press,
November 2000.
[252] The Olson Laboratory. Fight aids@home. http://fightaidsathome.

scripps.edu, 2003.
[253] U. et al. LECHNER. An object-oriented airport: Specification and refine-

ment in maude. In Computer Science, editor, Recent Trends in Data Type
Specifications, volume 906, chapter 351-367. Springer-Verlag, 1995.
[254] C. Lee and M. Handi. Parallel image processing applications on a network

of workstations. Parallel Computing, 21:137160, 1995.
[255] F. Leymann. Web services flow language, version 1.0, 2001.
[256] Especial Cosmo On Line. Declarao de ir pela internet bate recorde.

http://www.cosmo.com.br/especial/impostoderenda/
integra.asp?id=149890. ltima Visita em 11.09.2006 12:20.

[257] M. Litzkow, M. Livny, and M. Mutka. Condor: A hunter of idle worksta-

tions. In Proceedings of 8th Internetaional Conference of Distributed Computing
Systems, pages 104111, 1988.
[258] Michael Litzkow, Miron Livny, and Matthew Mutka. Condor - a hunter of
idle workstations. In Proceedings of the 8th International Conference of Distri-
buted Computing Systems, June 1988.
[259] V. Lo, J. Mache, and K. Windisch. A comparative study of real workload tra-
ces and synthetic workload models for parallel job scheduling. In D. Feitel-
son and L. Rudolph, editors, Job Scheduling Strategies for Parallel Processing,
volume 1459, pages 2546. Lecture Notes in Computer Science, Springer
Verlag, 1998.
[260] Olivier Lobry. Evaluation des systmes de fichiers pvfs et nfsp.

http://www-id.imag.fr/Laboratoire/Membres/Lobry_Olivier/
PVFS_NFSP/PVFS_NFSP.html. Ultima Visita em 20.09.2005 12:12.
[261] Pierre Lombard and Yves Denneulin. Nfsp: A distributed nfs ser-
ver for cluster of workstations. http://ka-tools.sourceforge.net/
publications/nfsp-ipdps01.pdf. Ultima Visita em 20.09.2005 12:12.
[262] B. Lowekamp, N. Miller, D. Sutherland, T. Gross, P. Steenkiste, and J. Subh-

lok. A resource query interface for network-aware applications. In Seventh
IEEE Symposium on High-Performance Distributed Computing, July 1998.
[263] Peter Lyman, Hal R. Varian, James Dunn, Aleksey Strygin, and Kirsten
Swearingen. How much information? http://www.sims.berkeley.edu/
research/projects/how-much-info-2003, October 2003.
[264] S. Machiraju, M. Seshadri, and D. Geels. Introspective prefetching for mo-

bile users in oceanstore, 2002.
[265] M. Maheswaran, S. Ali, H. J. Siegel, D. H., and R. F. Freund. Dynamic

mapping of a class of independent tasks onto heterogeneous computing
systems. Journal of Parallel and Distributed Computing, 59(2):107131, 1999.
[266] M. Maheswaran, S. Ali, H. J. Siegel, D. A. Hensgen, and R. F. Freund. Dy-

namic matching and scheduling of a class of independent tasks onto hete-
rogeneous computing systems. In 8th Heterogeneous Computing Workshop,
pages 3045, San Juan, Puerto Rico, April 1999.

[267] K. Marzullo, M. Ogg, A. Ricciardi amd A. Amoroso, A. Calkins, and

E. Rothfus. Nile: Wide-area computing for high energy physics. In Pro-
ceedings 7th ACM European Operating Systems Principles Conference. System
Support for Worldwide Applications, pages 5459, Connemara, Ireland, Sep-
tember 1996. ACM Press.
[268] Marta Mattoso, Geraldo Zimbro, Alexandre A. B. Lima, and Fernanda

Baio. Pargres: Middleware para processamento paralelo de consultas olap
em clusters de banco de dados.
[269] Tom McNeal and Chuck Lever. Linux nfs faq. http://nfs.sourceforge.
net. Ultima Visita em 20.09.2005 12:12.
[270] Corinto Meffe. Software pblico diferencial para o brasil.

http://computerworld.uol.com.br/governo/
corinto_meffe/idgcoluna.2006-06-09.2677471526
/IDGColunaPrint_view. ltima Visita em 11.09.2006 12:20.
[271] Corinto Meffe, Carlos Castro, Anderson Peterle, Nazar Bretas, and Rog-
rio Santanna. Materializao do conceito de software pblico: Iniciativa
cacic. http://guialivre.governoeletronico.gov.br/cacic/
sisp2/info/software_publico.html. ltima Visita em 11.09.2006 12:20.
[272] Corinto Meffe, Elias O. P. Mussi, Leonardo Mello, and Rogrio Santanna
dos Santos. A tecnologia de cluster e grid na resoluo de problemas de
governo eletrnico. The 18th International Symposium on Computer Archite-
ture and High Performance Computing, pages 18, Outubro 2006.
[273] P MEHROTRA. Data parallel programming: The promises and limitations

of high performance fortran. In Computer Science, editor, Computer Science,
volume 734, chapter 1. Springer-Verlag, 1993.
[274] Ethan L. Miller and Randy H. Katz. Rama: A file system for massively-
parallel computers. http://ssrc.cse.ucsc.edu/~elm/Papers/mss93.
pdf. Ultima Visita em 20.09.2005 12:12.
[275] Ethan L. Miller and Randy H. Katz. Rama: An easy-to-use, high-

performance parallel file system. http://ssrc.cse.ucsc.edu/~elm/
Papers/pc97.pdf. Ultima Visita em 20.09.2005 12:12.
[276] V. MILUINOVIC. Scanning the issue: Special issue on distributed shared

memory systems. Proceedings of the IEEE, 87(3):1, March 1999.

[277] Dan I MOLDOVAN. Parallel Processing From Applications to Systems. Mor-

gan Kaufmann Publishers, 1993.
[278] T. N. Moretti, C. O.; Bittencourt. Aspectos gerais da computao paralela

e do sistema pvm. Technical report, Escola Politcnica da Universidade de
So Paulo, Boletim Tcnico, BT/PEF-9709, ISSN 0103-9822, 1997.
[279] R. S. Morrison. Cluster Computing Theory. Richard S. Morrison, GNU Gene-

ral Public Licence, 2003.
[280] H. Stephen MORSE. Practical Parallel Computing. Academic Press, Inc, 1994.
[281] M. V MUTHUKUMAR, K.; HERMENEGILDO. Complete and effici-

ent methods for supporting side-effects in independent/restricted and-
parallelism. In INTERNATIONAL CONFERENCE ON LOGIC PROGRAM-
MING, 1989.
[282] M. V MUTHUKUMAR, K.; HERMENEGILDO. Determination of variable

dependence information through abstract interpretation. In NORTH AME-
RICAN CONFERENCE ON LOGIC PROGRAMMING, 1989.
[283] Myricom. News & events archive myricom. http://www.myricom.com/

news/. Ultima Visita em 20.09.2005 12:12.
[284] Myricom. Performance measurements. http://www.myricom.com/

myrinet/performance/index.html. Ultima Visita em 20.09.2005 12:12.
[285] M. Nelson, B. Welch, and J. Ousterhout. Caching in the sprite network file
system. 1987.
[286] Zsolt Nemeth and Vaidy Sunderam. A formal framework for defining grid
systems. In Proceedings of the Second IEEE/ACM International Symposium on
Cluster Computing and the Grid. IEEE Computer Society Press, Maio 2002.
[287] NeSC. National e-science centre. http://www.nesc.ac.uk/, 2005.
[288] Marco A. S. Netto et al. Transparent resource allocation to exploit idle clus-
ter nodes for execution of independent grid tasks. In Proceedings of the first
international conference on e-Science and grid computing, pages 238245, Mel-
bourne, 2005. IEEE Computer Society.
[289] Marco Aurlio Stelmar Netto and Csar A.F. De Rose. CRONO: A confi-
gurable and easy to maintain resource manager optimized for small and

mid-size GNU/Linux cluster. In Proceedings of the 2003 International Confe-

rence on Parallel Processing, pages 555562, Kaohsiung, 2003. IEEE Computer
Society.
[290] Tsuen-Wan Johnny Ngan, Animesh Nandi, and Atul Singh. Fair
bandwidth and storage sharing in peer-to-peer networks. In Proceedings
of, Jan 2003.
[291] N. Nieuwejaar, D. kootz, A. Purakayastha, C. S. Ellis, and M. L. Best. File-

access characteristics of parallel scientific workloads. IEEE Transactions on
Parallel and Distributed Systems, 7(10):10751089, october 1996.
[292] R. Novaes, P. Roisenberg, R. Scheer, C. Northfleet, J. Jornada, and W. Cirne.

Non-dedicated distributed environment: A solution for safe and continu-
ous exploitation of idle cycles. In Proceedings of the AGridM 2003 - Workshop
on Adaptive Grid Middleware, 2003.
[293] R. Oldfield. Summary of existing and developing data grids - draft. In Grid
Forum. Remote Data Access Working Group. IEEE Computer Society Press,
March 2001.
[294] OpenMP. Simples, portable, scalable smp programming. http://www.

openmp.org, December 2003.
[295] C. Osthoff, P. Barros, C. Veronez, F. Agostini, W. Cirne, E. Santos-Neto,

L. Costa, F. Silva, P. Pascutti, P. Bisch, and A. Silva. Utilizao do software
mygrid para adaptar uma aplicao de dinmica molecular em um grid de
7 domnios. In Technical Report LNCC, LNCC, Rio de Janeiro, Brasil, 2002.
[296] John Ousterhout. A brief retrospective on the sprite network operating sys-
tem. ABriefRetrospectiveontheSpriteNetworkOperatingSystem. Ul-
tima Visita em 20.09.2003 12:12.
[297] S.P. Pacheco. A users guide to mpi. http://nexus.cs.usfca.edu/mpi/.

[298] GIMPS Home Page. The great internet mersenne prime search. http://
www.merssene.org, December 2003.
[299] D. Paranhos, W. Cirne, and F. Brasileiro. Trading cycles for information:

Using replication to schedule bag-of-tasks applications on computational
grids. In Proceedings of the Euro-Par 2003: International Conference on Parallel
and Distributed Computing, Klagenfurt,Austria, August 2003.

[300] Simon PEYTON-JONES. Implementing Functional Programming Languages.

International Series in Computer Science, Prentice-Hall, 1992.
[301] M. Pinedo. Scheduling: Theory, Algorithms and Systems. Prentice Hall, 2nd
edition, New Jersey, USA, August 2001.
[302] Jef Poskanzer. Bandwidth. http://www.acme.com/buildapc/

bandwidth.html. Ultima Visita em 20.09.2003 12:12.
[303] J. A. Pouwelse, P. Garbacki, D.H.J. Epema, and H. J. Sips. The bittorrent

p2p file-sharing system: Measurements and analysis.
[304] Dhiraj K. Pradhan. Fault Tolerant System Design. Prentice Hall, 1996.
[305] The Open MPI Project. Open mpi: Open source high performance compu-
ting. http://www.open-mpi.org/. Ultima Visita em 20.04.2005 12:20.
[306] J. et al. PROTIC. Distributed Shared Memory: Concepts and Systems. IEEE
Computer Society Press, 1998.
[307] PVM. Pvm: Parallel virtual machine. http://www.csm.ornl.gov/pvm/.

[308] Harish Ramachandran. Design and implementation of the system inter-

face for pvfs2. ftp://ftp.parl.clemson.edu/pub/techreports/2002/
PARL-2002-008.ps. Ultima Visita em 20.09.2005 12:12.
[309] K. Ranganathan and I. Foster. Decoupling computation and data schedu-

ling in distributed data-intensive applications. In High Performance Distri-
buted Computing, 2002. Proceedings. 11th IEEE International Symposium, Edin-
burg, Scotland, July 2002. IEEE Computer Society Press.
[310] J. L. Reyes and J. Fernandez Haeger. Sequential co-operative load transport

in the seed-harvesting ant messor barbarus. Insectes Sociaux, 46:119125,
1999.
[311] R. Ribler, J. Vetter, H. Simitci, and D. Reed. Autopilot: Adaptive control of

distributed applications. In Proceedings of the 7th IEEE Symposium on High-
Performance Distributed Computing, July 1998.
[312] C. Rolland. Latex: Guide Pratique. Addison-Wesley France, SA, 1995.

[313] C. De Rose, F. Blanco, N. Maillard, K. Saikoski, R. Novaes, O. Richard, and

B. Richard. The virtual cluster: A dynamic environment for exploitation
of idle network resources. In Proceedings of 14th Symposium on Computer
Architectures and High Performance Computing, 2002.
[314] C. De Rose and P. Navaux. Fundamentos de processamento de alto de-

sempenho. In ERAD 2002 - 2a Escola Regional de Alto Desempenho, Janeiro
2002.
[315] Rob Ross, Walt Ligon, , and Phil Carns. Parallel virtual file system. http://
www.parl.clemson.edu/pvfs2/sc2002-whitepaper-pvfs.pdf. Ultima
Visita em 20.09.2005 12:12.
[316] D. De Roure, N. R. Jennings, and N. R. Shadbolt. The semantic grid: Past,

present and future. In Proceedings of the IEEE, volume 93, 2003.
[317] David De Roure, Mark A. Baker, Nicholas R. Jennings, and Nigel R. Shad-
bolt. The evolution of the Grid. Int. J. of Concurrency and Computation: Prac-
tice and Experience, to appear.
[318] Antony I. T. Rowstron and Peter Druschel. Storage management and ca-
ching in PAST, a large-scale, persistent peer-to-peer storage utility. In Sym-
posium on Operating Systems Principles, pages 188201, 2001.
[319] Alex Salkever. Trading cpu time like corn? http://yahoo.businessweek.

com/technology/content/nov2004/tc2004119_3747_tc162.htm, No-
vember 2004.
[320] E. Santos-Neto. A knowledge-free scheduling approach to improve the per-

formance of data intensive grid applications. In Proceedings of Research Col-
loquium on Third IFIP Conference, September 2003.
[321] E. Santos-Neto, W. Cirne, F. Brasileiro, and A. Lima. Exploiting replication

and data reuse to efficiently schedule data-intensive applications on grids.
Lecture Notes in Computer Science, 3277:210232, 2005.
[322] E. L. Santos-Neto, L. E. F. Tenrio, E. J. S. Fonseca, S. B. Cavalcanti, and

J. M. Hickmann. Parallel visualization of the optical pulse through a doped
optical fiber. In Proceedings of Annual Meeting of the Division of Computational
Physics (abstract), June 2001.
[323] Elizeu Santos-Neto. Comparative performance analysis between mygrid

2.1.3 and mygrid 3.0. In HP-OurGrid-Technical Report, 2004.

[324] L. F. G. Sarmenta. Sabotage-tolerance mechanisms for volunteer computing

systems. Future Generation Computer Systems, 18(4):561572, 2002.
[325] L. F. G. Sarmenta and Satoshi Hirano. Bayanihan: building and studying

Web-based volunteer computing systems using Java. Future Generation
Computer Systems, 15(5-6):675686, 1999.
[326] E. Sarmiento. Inside jail. http://www.daemonnews.org/200109/

jailint.html, 2001.
[327] Mahadev Satyanarayanan, James J. Kistler, Lily B. Mummert, Maria R.

Ebling, Punnet Kumar, and Qi Lu. Experience with disconnected opera-
tion in a mobile computing environment. http://www-2.cs.cmu.edu/
afs/cs/project/coda/Web/docdir/mobile93.pdf. Ultima Visita em
20.09.2005 12:12.
[328] Michael F. Schwartz. A scalable, non-hierarchical resource discovery me-

chanism based on probabilistic protocols. Technical Report, CU-CS-474-90,
June 1990.
[329] G. Shao, R. Wolski, and F. Berman. Predicting the cost of redistribution in

scheduling. In Proceedings of the 8th SIAM Conference on Parallel Processing
for Scientific Computing, 1997.
[330] S. Shepler, B. Callaghan, D. Robinson, R. Thurlow, C. Beame, M. Eisler, and

D. Noveck. Network file system (nfs) version 4 protocol. http://rfc-ref.
org/RFC-TEXTS/3530/index.html. Ultima Visita em 20.09.2005 12:12.
[331] Ken Shirri. The sprite operating system. http://www.cs.berkeley.edu/

projects/sprite/sprite.html. Ultima Visita em 20.09.2005 12:12.
[332] David SKILLICORN. Fundations of Parallel Programming. Cambridge: Uni-

versity Press, 1994.
[333] Domenico SKILLICORN, David B.; TALIA. Models and languages for pa-
rallel computation. ACM Computing Surveys, 30(2):123169, june 1998.
[334] Joseph D. Sloan. Ten tips for building your first high-performance
cluster. http://www.linuxdevcenter.com/pub/a/linux/2004/12/29/
lnxclstrs_10.html. Ultima Visita em 20.05.2006 12:20.
[335] S. Smallen, H. Casanova, and F. Berman. Applying scheduling and tuning

to on-line parallel tomography, November 2001.

[336] S. Smallen, W. Cirne, and J. Frey et. al. Combining workstations and super-
computers to support grid applications: The parallel tomography experi-
ence, 2000.
[337] J. Smith and S. K. Shrivastava. A system for fault-tolerant execution of data

and compute intensive programs over a network of workstations. In Lecture
Notes in Computer Science, volume 1123. IEEE Press, 1996.
[338] W. Smith. A framework for control and observation in distributed environ-

ments. In NASA Advanced Supercomputing Division, NASA Ames Research
Center, Moffett Field, CA. NAS-01-006, June 2001.
[339] W. Smith, I. Foster, and V. Taylor. Predicting application run times using
historical information. Lecture Notes in Computer Science, 1459:122142, 1998.
[340] W. Smith, I. Foster, and V. Taylor. Scheduling with advanced reservations.

In Proceedings of the IPDPS Conference, May 2000.
[341] Steven R. Soltis, Thomas M. Ruwart, and Matthew T. OKeefe. The global
file system. http://www.diku.dk/undervisning/2003e/314/papers/
soltis97global.pdf. Ultima Visita em 20.09.2005 12:12.
[342] I. Sommerville. Software Engineering. Pearson Education Deutschland

GmbH, 6th edition, 2001.
[343] S. Son and M. Livny. Recovering internet symmetry in distributed sys-

tems computing. In Proceedings of GAN - Workshop on Grids and Advanced
Networks, 2003.
[344] R. Sosic. Introspective computer systems. Electrotechnical Review, 59(5):292

298, December 1992.
[345] B. Sotomayor. Globus toolkit 3 tutorial. http://gdp.globus.org/

gt3-tutorial/, 2004.
[346] E. STERLING, L; SHAPIRO. The Art of Prolog. 2a Ed. Cambridge: MIT

Press, 1994.
[347] J. Stiles, T. Bartol, E. Salpeter, and M. Salpeter. Monte carlo simulation

of neuromuscular transmitter release using mcell, a general simulator of
cellular physiological processes. Computational Neuroscience, 1998.

[348] James Surowiecki. The Wisdom of Crowds: Why the Many Are Smarter Than
the Few and How Collective Wisdom Shapes Business, Economies, Societies and
Nations. Doubleday, May 2004.
[349] D Talia. Parallelism in knowledge discovery techniques. Springer-verlag

Berlin, 2367:127136, 2002.
[350] Siew-Joo Tan. Survey reveals web services are fulfilling their promises. In
Yakee Group Report, September 2004.
[351] Andrew S. Tanenbaum. Modern Operating Systems. Prentice Hall, 1992.
[352] Albert S. TANENBAUM, Andrew S.; WOODHULL. Sistemas operaci-

onais: projeto e implementao. Bookman, 1999.
[353] Maarten Van. TANENBAUM, Andrew S.; STEEN. Distributed sys-

tems: principles and paradigms. Prentice Hall, 2002.
[354] PVFS2 Development Team. Parallel virtual file system, version 2. http:
//www.pvfs.org/pvfs2/pvfs2-guide.html. Ultima Visita em 20.09.2005
12:12.
[355] TechFest. Ethernet technical summary. http://www.techfest.com/

networking/lan/ethernet4.htm. Ultima Visita em 20.09.2005 12:12.
[356] Altair Grid Technologies. Openpbs technical overview. http://www.

openpbs.org/overview.html. Ultima Visita em 20.04.2006 12:20.
[357] Douglas Thain, Jim Basney, Se-Chang Son, and Miron Livny. The kangaroo
approach to data movement on the grid. In Proceedings of the 10th IEEE Sym-
posium on High Performance Distributed Computing. IEEE Computer Society
Press, May 2001.
[358] Douglas Thain, Todd Tannenbaum, and Miron Livny. Condor and the grid.
In Fran Berman, Geoffrey Fox, and Tony Hey, editors, Grid Computing: Ma-
king the Global Infrastructure a Reality. John Wiley and Sons Inc., December
2002.
[359] Alok THAKUR, Rajeev; CHOUDHARY. Efficient algorithms for array re-
distribution. IEEE Transactionson Parallel and Distributed Systems, 6(7):587
594, june 1996.

[360] Rajeev Thakur. Romio: A high-performance, portable mpi-io imple-

mentation. http://www-unix.mcs.anl.gov/romio/. Ultima Visita em
20.09.2005 12:12.
[361] S. Thatte. XLANG: Web services for business process design, 2001.
[362] Patrick Thibodeau. Sun to allow grid use sales on e-trading

market. http://computerworld.com/managementtopics/ebusiness/
story/0,10801,99463,00.html, February 2005.
[363] B. Tierney, B. Crowley, D. Gunter, M. Holding, J. Lee, and M. Thompson. A

monitoring sensor management system for grid environments. In Procee-
dings of the IEEE High Performance Distributed Computing Conference (HPDC-
9), August 2000.
[364] TOP500. Top500.org. http://www.top500.org/. Ultima Visita em

20.04.2006 12:20.
[365] H. Topcuoglu, S. Hairi, and M. Wu. Performance-effective and low-

complexity task scheduling for heterogeneous computing. IEEE Trasactions
on Parallel and Distributed Systems, 13(3):260274, March 2002.
[366] Paulo R. Trezentos. Vitara: Network clustering como soluo para grandes
exigncias de processamento - apresentao e contextualizao. Technical
report, Projeto final de curso de IGE, ADETTI / ISCTE, 1999.
[367] W. W. Trigeiro, L. J. Thomas, and J. O. McClain. Capacitated lot sizing with

setup times. Managemeent Science, 35(3):353366, March 1989.
[368] S. Tuecke, K. Czajkowski, I. Foster, J. Frey, S. Graham, C. Kesselman, T. Ma-

quire, T. Sandholm, P. Vanderbilt, and D. Snelling. Open grid services in-
frastructure (ogsi) version 1.0. Global Grid Forum Draft Recommendation,
June 2003.
[369] H. T UNG. The structure of parallel algorithms. Advance in Computers,

19(1):6590, 1 1980.
[370] A. Vahdat, P. Eastham, C. Yoshikawa, E. Belani, T. Anderson, D. Culler, and

M. Dahlin. Webos: Operating system services for wide area applications.
In Proceedings of the Seventh Symposium on High Performance Distributed Com-
puting, 1998.

[371] L. G VALIANTE. A bridging model for parallel computation. Communica-

tions of the ACM, 33(8):103111, august 1990.
[372] S. Vazhkudai, J. M. Schopf, and I. Foster. Predicting the performance of

wide area data transfers. In Proceedings of the 16th Internetional Parallel and
Distributed Process Symposium. IEEE Computer Society Press, April 2002.
[373] Bill von Hagen. Exploring the ext3 filesystem. what is journaling? http:
//www.linuxplanet.com/linuxplanet/reports/4136/3/. Ultima Vi-
sita em 20.09.2005 12:12.
[374] Gregor von Laszewski. Grid Computing: Enabling a Vision for Collabora-
tive Research. In Juha Fagerholm, Juha Haataja, Jari Jrvinen, Mikko Lyly,
Peter Raback, and Ville Savolainen, editors, The Sixth International Confe-
rence on Applied Parallel Computing, volume 2367 of Lecture Notes in Computer
Science, pages 3752, Espoo, Finland, 15-18 June 2002. Springer.
[375] Gregor von Laszewski, Gail Pieper, and Patrick Wagstrom. Performance
Evaluation and Characterization of Parallel and Distributed Computing Tools,
chapter Gestalt of the Grid. Wiley Book Series on Parallel and Distribu-
ted Computing. to be published 2002.
[376] W3C. World wide web consortium (w3c). http://www.w3c.org. Ultima

Visita em 24.01.2005 12:20.
[377] A. Waheed, W. Smith, J. George, and J. Yan. An infrastructure for moni-

toring and management in computational grids. In Proceedings of the 2000
Conference on Languages, Compilers, and Runtime Systems, 2000.
[378] A. Waheed, W. Smith, J. George, and J. Yan. An infrastructure for moni-

toring and management in computational grids. In Proceedings of the 2000
Conference on Languages, Compilers, and Runtime Systems, 2000.
[379] C. Waldspurger and W. Weihl. Stride scheduling: Deterministic

proportional-share resource mangement. In Technical Memorandum
MIT/LCS/TM-528 (MIT Laboratory for Computer Science), June 1995.
[380] David D.H WARREN. An abstract prolog instruction set. Technical report,
Manchester: SRI International, 1983.
[381] J. Weissman. Gallop: The benefits of wide-area computing for parallel pro-
cessing. Journal of Parallel and Distributed Computing, 54(2), November 1998.

[382] J. Weissman and Andrew Grimshaw. A framework for partitioning parallel

computations in heterogeneous environments. Concurrency: Practice and
Experience, 7(5), August 1995.
[383] Von Welch, Frank Siebenlist, Ian Foster John Bresnahan, Karl Czajkowski,
Jarek Gawor, Carl Kesselman, Sam Meder, Laura Pearlman, and Steven Tu-
ecke. Security for grid services. In Twelfth International Symposium on High
Performance Distributed Computing (HPDC-12), June 2003.
[384] Wikipedia. 10 gigabit ethernet. http://www.wikipedia.org/wiki/10_

Gigabit_Ethernet. Ultima Visita em 20.09.2005 12:12.
[385] Wikipedia. Internet scsi. http://www.wikipedia.org/wiki/ISCSI. Ul-

tima Visita em 20.09.2005 12:12.
[386] Wikipedia. Pio mode. http://en.wikipedia.org/wiki/Programmed_

input/output. Ultima Visita em 20.09.2005 12:12.
[387] Wikipedia. Scsi. http://en.wikipedia.org/wiki/Scsi. Ultima Visita

em 20.09.2005 12:12.
[388] Wikipedia. Serial ata. http://en.wikipedia.org/wiki/Serial_ata. Ul-

tima Visita em 20.09.2005 12:12.
[389] WikiPedia. Wikipedia, the free encyclopedia. http://pt.wikipedia.

org/wiki/Mainframes. Ultima Visita em 20.04.2005 12:20.
[390] WikiPedia. Wikipedia, the free encyclopedia. http://en.wikipedia.

org/wiki/Block_device. Ultima Visita em 20.04.2005 12:20.
[391] R. Wolski, N. Spring, and J. Hayes. Predicting the CPU availability of time-
shared unix systems on the computational grid. In Proceedings of 8th Inter-
national Symposium on High Performance Distributed Computing (HPDC99),
August 1999.
[392] R. Wolski, N. T. Spring, and J. Hayes. The network weather service: a

distributed resource performance forecasting service for metacomputing.
Future Generation Computer Systems, 15(5-6):757768, 1999.
[393] Adenauer Corra Yamin. Um Estudo das Potencialidades e Limites na Explora-

o do Paralelismo. 2006.

[394] Yifeng Zhu, Hong Jiang, Xiao Qin, Dan Feng, and David R. Swanson. Im-
proved read performance in ceft-pvfs: Cost efective, fault-tolerant paral-
lel virtual file system. http://www.cs.nmt.edu/~xqin/pubs/ccgrid03.
pdf. Ultima Visita em 20.09.2005 12:12.

Guiacluster PDF

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Guiacluster PDF

Enviado por

Direitos autorais:

Formatos disponíveis

Ministrio do Planejamento, Oramento e Gesto

SLTI Secretaria de Logstica e Tecnologia da Informao

Ministro de Estado do Planejamento, Oramento e Gesto

Ministro de Estado da Casa Civil

Secretrio de Logstica e Tecnologia da Informao

Guia de Estruturao e Administrao do Ambiente de Cluster e Grid.

1. Cluster e Grid. 2. Governo Eletrnico. 3. Tecnologias da

Secretaria de Logstica e Tecnologia da Informao - SLTI

Claudete Bezerra da Silva

Alex Sandro Soares

VERSAO 1.0 PGINA V

Elias Otvio de Paula Mussi

Coordenao do Projeto de Cluster e Grid

Rogrio Santanna dos Santos

VERSAO 1.0 PGINA VI

A complexidade das tecnologias tratadas neste Guia requer a participao freqente da

O intuito de contar com a participao de especialistas, desde a primeira verso do Guia,

No seria possvel manter as informaes atualizadas e inserir o que h de mais moderno

VERSAO 1.0 PGINA VII

Data Verso Autor Alterao

VERSAO 1.0 PGINA VIII

Nota Tcnica da Comisso de Redao

As diretrizes que compem este documento tm como base as definies do Go-

As orientaes tcnicas so fundamentadas em pesquisadores brasileiros e nas

A tecnologia de Cluster e Grid, embora recente, possui um amplo acervo de ar-

O lanamento desta verso final representa a consolidao dos trabalhos de in-

VERSAO 1.0 PGINA IX

Secretaria de Logstica e Tecnologia da Informao. Verso 0.5

Verso 0.5 Encontro Mineiro de Software Livre 2006.

Verso 0.5 ParGov - SBAC-PAD 2006.

Verso 0.5 III Frum Goiano de Software Livre. Realizado na cidade

Verso 0.6 IV CONISLI - Congresso Internacional de Software Livre.

Verso 0.6 III LatinoWare 2006 - III CONFERNCIA LATINOAMERI-

Verso 1.0 8 FISL - 8 Frum Internacional Software Livre. Realizado

VERSAO 1.0 PGINA X

Governo Brasileiro a reproduo em parte ou totalmente autorizada desde

Figura 1: Creative Commons

VERSAO 1.0 PGINA XI

Lista de figuras xxiv

Lista de tabelas xxviii

1.1 Abreviaes e Terminologia . . . . . . . . . . . . . . . . . . . . . . . xxxi

1.2 Pblico . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxxii

1.3 Autores . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxxii

1.4 Agradecimentos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxxiii

2 Governo Eletrnico e Novas Concepes Tecnolgicas 2

2.1 A Informtica Pblica Brasileira . . . . . . . . . . . . . . . . . . . . . 2

2.1.1 A Sociedade da Informao e a Inovao Tecnolgica . . . . 5

VERSAO 1.0 PGINA XII

2.2 Governo Eletrnico Brasileiro . . . . . . . . . . . . . . . . . . . . . . 8

2.2.1 Diretrizes do Governo Eletrnico Brasileiro . . . . . . . . . . 10

2.2.2 Padres de Interoperabilidade de Governo Eletrnico . . . . 11

2.2.3 As Diretrizes do Governo Eletrnico e o Software Livre . . . 14

2.2.4 A Arquitetura de Cluster e Grid e as Diretrizes do Governo

2.3 As Novas Demandas Computacionais . . . . . . . . . . . . . . . . . 18

2.3.1 Computao sob Demanda . . . . . . . . . . . . . . . . . . . 25

2.3.2 Aproveitamento de Ciclos Ociosos . . . . . . . . . . . . . . . 26

2.4 Dois Paradigmas Computacionais . . . . . . . . . . . . . . . . . . . 27

2.4.1 Computao de Grande Porte . . . . . . . . . . . . . . . . . . 28

2.4.2 Computao Distribuda . . . . . . . . . . . . . . . . . . . . . 30

2.4.3 Comparao: Grande Porte e Distribuda . . . . . . . . . . . 30

2.4.4 As Geraes da Computao Distribuda . . . . . . . . . . . 33

3.1 Vantagens Tcnicas de Utilizao de Cluster e Grid . . . . . . . . . 39

3.2 Arquitetura para sistemas crticos online em N Camadas . . . . . . 40