You are on page 1of 456

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 Bibliograa. 1. Cluster e Grid. 2. Governo Eletrnico. 3. Tecnologias da

Informao e Comunicao.

4. Agregados Computacionais.

A menos que modiquemos 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 Elias Otvio de Paula Mussi

Coordenao do Projeto de Cluster e Grid Corinto Meffe Elias Otvio de Paula Mussi 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 inconsistncias 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 complexidade 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 01/12/05 0.0 01/02/06 0.1 10/02/06 0.1.5 Autor Elias Mussi Trabalhos provindos equipe interna da SLTI. Elias Mussi Alterao Estruturao do Sumrio Verso inicial de desenvolvimento de contedo. Proposta do Sistema de consulta e contribuio on-line para o Guia de Cluster Sesses sobre Paralelismo e Sistema de Imagem nica (SSI).

da

05/05/06 0.2

17/06/06 0.3

Contribuies do Prof. Adenauer Yamin (PPAD), de Lucius Curado (SSI). Mais trabalhos da equipe da SLTI Elias Mussi

14/08/06 0.3.5

Equipe SLTI

14/08/06 0.4 01/09/06 0.4.5 04/10/06 0.5

Contribuio de Walfredo Cirne e Elizeu Santos-Neto. Equipe SLTI Contribuio de Marco Sinhoreli e trabalhos da Equipe SLTI Contribuio de Roberto Pires de Carvalho e trabalhos da Equipe SLTI Equipe SLTI Equipe SLTI

Disponibilizao do Sistema de Consulta e Colaborao do Guia de Cluster no endereo http://guialivre. governoeletronico. gov.br/guiaonline/ guiacluster/ Expanso do contedo do documento, principalmente na parte III. Captulo Grid Computing. Expanso de contedo, principalmente da Parte II. Captulo sobre Virtualizao; Expanso de contedo, principalmente da Parte III Sesso de Armazenamento Distribudo. Expanso do contedo do documento e correes. Expanso do contedo e correes.

22/10/06 0.6

24/11/06 0.7 01/04/07 1.0

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 denies do Governo 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 arquiteturas, modelos, ferramentas, middlewares e aplicativos. A equipe tcnica responsvel pela elaborao deste documento conta com a colaborao da Comunidade Acadmica e de Software Livre para suprir lacunas originadas pela complexidade e pela abrangncia do contedo do Guia de Cluster. O lanamento desta verso nal representa a consolidao dos trabalhos de insero de contedo e a devoluo sociedade do resultado do trabalho at este instante, o qual j conta com importantes colaboraes de membros da comunidade 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. Secretaria de Logstica e Tecnologia da Informao. Secretaria de Logstica e Tecnologia da Informao. Secretaria de Logstica e Tecnologia da Informao. Verso 0.5 Verso 0.6 Verso 0.7 Verso 1.0

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/. ParGov SBAC-PAD 2006. The 18th International Symposium on Computer Architeture 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/. III Frum Goiano de Software Livre. Realizado na cidade de Goiania - GO entre os dias 27-28 de outubro de 2006. 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. III LatinoWare 2006 - III CONFERNCIA LATINOAMERICANA DE SOFTWARE LIVRE. Realizado na cidade de Foz do Iguau - PR entre os dias 16 e 17 de Novembro de 2006. 8 FISL - 8 Frum Internacional Software Livre. Realizado na cidade de Porto Alegre - RS entre os dias 12 e 14 de abril de 2007.

Verso 0.5

Verso 0.5

Verso 0.6

Verso 0.6

Verso 1.0

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

General Public License cujo contedo est disponibilizado no Apndice A.


1.0 PGINA XI

VERSAO

Sumrio

Sumrio

xi

Lista de guras

xxiv

Lista de tabelas

xxviii

1 Prefcio 1.1 1.2 1.3 1.4

xxxi

Abreviaes e Terminologia . . . . . . . . . . . . . . . . . . . . . . . xxxi Pblico . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxxii Autores . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxxii Agradecimentos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxxiii

I Diretrizes Gerais
2 Governo Eletrnico e Novas Concepes Tecnolgicas 2.1 A Informtica Pblica Brasileira . . . . . . . . . . . . . . . . . . . . . 2.1.1
VERSAO

1
2 2 5

A Sociedade da Informao e a Inovao Tecnolgica . . . .

1.0

PGINA XII

G UIA DE C LUSTER

SUMRIO

2.2

Governo Eletrnico Brasileiro . . . . . . . . . . . . . . . . . . . . . . 2.2.1 2.2.2 2.2.3 2.2.4 Diretrizes do Governo Eletrnico Brasileiro . . . . . . . . . . Padres de Interoperabilidade de Governo Eletrnico . . . . As Diretrizes do Governo Eletrnico e o Software Livre . . . A Arquitetura de Cluster e Grid e as Diretrizes do Governo Eletrnico . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

8 10 11 14

17 18 25 26 27 28 30 30 33

2.3

As Novas Demandas Computacionais . . . . . . . . . . . . . . . . . 2.3.1 2.3.2 Computao sob Demanda . . . . . . . . . . . . . . . . . . . Aproveitamento de Ciclos Ociosos . . . . . . . . . . . . . . .

2.4

Dois Paradigmas Computacionais . . . . . . . . . . . . . . . . . . . 2.4.1 2.4.2 2.4.3 2.4.4 Computao de Grande Porte . . . . . . . . . . . . . . . . . . Computao Distribuda . . . . . . . . . . . . . . . . . . . . . Comparao: Grande Porte e Distribuda . . . . . . . . . . . As Geraes da Computao Distribuda . . . . . . . . . . .

II Aspectos Gerenciais
3 Introduo 3.1 3.2 Vantagens Tcnicas de Utilizao de Cluster e Grid . . . . . . . . . Arquitetura para sistemas crticos online em N Camadas . . . . . . 3.2.1
VERSAO

35
36 39 40 41

Camada de Aplicao . . . . . . . . . . . . . . . . . . . . . .

1.0

PGINA XIII

G UIA DE C LUSTER

SUMRIO

3.2.2 3.2.3 3.2.4 3.2.5 3.3

Camada de Banco de Dados . . . . . . . . . . . . . . . . . . . Camada de Armazenamento . . . . . . . . . . . . . . . . . . Diagrama da arquitetura proposta . . . . . . . . . . . . . . . Consideraes sobre a arquitetura . . . . . . . . . . . . . . .

41 41 42 43 43 46 48 50 52 54

Possibilidades de Aplicaes Prticas de Cluster e Grid . . . . . . . 3.3.1 3.3.2 3.3.3 3.3.4 3.3.5 Cenrio - Aplicaes WEB . . . . . . . . . . . . . . . . . . . . Cenrio - Minerao de Dados . . . . . . . . . . . . . . . . . Cenrio - Processamento de Alto Desempenho . . . . . . . . Cenrio - Alta Disponibilidade . . . . . . . . . . . . . . . . . Cenrio - Banco de Dados . . . . . . . . . . . . . . . . . . . .

4 Viso Geral 4.1 4.2 A sensibilizao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Os Recursos Humanos Envolvidos . . . . . . . . . . . . . . . . . . . 4.2.1 4.2.2 4.3 Aperfeioamento dos Tcnicos . . . . . . . . . . . . . . . . . Consultoria . . . . . . . . . . . . . . . . . . . . . . . . . . . .

56 56 57 57 57 58 59

O Projeto de Cluster . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.3.1 O que deve ser observado . . . . . . . . . . . . . . . . . . . .

5 Processamento Paralelo: Sua Difuso e Uso 5.1


VERSAO

69 70

Aspectos para a Adoo do Processamento Paralelo . . . . . . . . .

1.0

PGINA XIV

G UIA DE C LUSTER

SUMRIO

5.1.1

Barreiras ao Crescimento da Freqncia de Operao dos Processadores . . . . . . . . . . . . . . . . . . . . . . . . . . . Largura de Banda no Acesso Memria . . . . . . . . . . . . Paralelismo Intrnseco do Mundo Real . . . . . . . . . . . . . A Relao Custo-Benefcio dos Processadores de ltima Gerao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Aplicaes Extremamente Complexas . . . . . . . . . . . . . Suporte Tolerncia a Falhas . . . . . . . . . . . . . . . . . . Crescimento Modular . . . . . . . . . . . . . . . . . . . . . . Disponibilidade de Software Aplicativo . . . . . . . . . . . . Relao entre a Teoria e a Tecnologia . . . . . . . . . . . . . .

70 71 72

5.1.2 5.1.3 5.1.4

72 73 74 74 76 77

5.1.5 5.1.6 5.1.7 5.1.8 5.1.9

III Aspectos Tcnicos


6 Conceitos Bsicos 6.1 Arquiteturas Computacionais . . . . . . . . . . . . . . . . . . . . . . 6.1.1 6.1.2 6.1.3 6.1.4

78
79 79

A Classicao de Flynn para Arquiteturas de Computadores 80 Multiprocessadores . . . . . . . . . . . . . . . . . . . . . . . . Multicomputadores . . . . . . . . . . . . . . . . . . . . . . . Multiprocessadores Simtricos (Symmetric Multiprocessors SMP) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ccNUMA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86 87

87 88

6.1.5
VERSAO

1.0

PGINA XV

G UIA DE C LUSTER

SUMRIO

6.1.6 6.1.7 6.1.8 6.1.9 6.2

Processadores Massivamente Paralelos - MPP . . . . . . . . Sistemas Distribudos . . . . . . . . . . . . . . . . . . . . . . Clusters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Grids . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

88 89 90 90 90 91 92 94 95 98 99

Dependabilidade . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.2.1 6.2.2 6.2.3 Ameaas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Meios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Atributos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

6.3 6.4 6.5 6.6

Escalonamento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Alta Disponibilidade . . . . . . . . . . . . . . . . . . . . . . . . . . . Balanceamento de Carga . . . . . . . . . . . . . . . . . . . . . . . . .

Redes de Comunicaes . . . . . . . . . . . . . . . . . . . . . . . . . 100 6.6.1 6.6.2 6.6.3 6.6.4 A Importncia da Rede de Comunicao . . . . . . . . . . . 100 Redes de Interconexo Utilizadas em Arquiteturas Paralelas 100 Topologias da Rede de Interconexo . . . . . . . . . . . . . . 103 Dispositivos de interconexo . . . . . . . . . . . . . . . . . . 106

6.7

Protocolos de Comunicao . . . . . . . . . . . . . . . . . . . . . . . 111 6.7.1 6.7.2 Frame Relay . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111 Asynchronous Transfer Mode . . . . . . . . . . . . . . . . . . . 111
PGINA XVI

VERSAO

1.0

G UIA DE C LUSTER

SUMRIO

6.7.3 6.7.4 6.7.5 6.7.6 6.7.7 6.7.8 6.7.9

FDDI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112 Modelo OSI . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112 Protocolo IP . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113 Transmission Control Protocol . . . . . . . . . . . . . . . . . . . 113 User Datagram Protocol . . . . . . . . . . . . . . . . . . . . . . 114 Real-time Transport Protocol . . . . . . . . . . . . . . . . . . . . 114 Virtual Router Redundancy Protocol . . . . . . . . . . . . . . . 114

7 Cluster de Armazenamento 7.1 7.2

117

Introduo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117 Block Devices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118 7.2.1 7.2.2 7.2.3 7.2.4 7.2.5 Arranjo Redundante de Discos - RAID . . . . . . . . . . . . 119 RAID via Hardware e via Software . . . . . . . . . . . . . . . 120 Distributed Replicated Block Device - DRBD . . . . . . . . . . . 121 Global Network Block Device - GNBD . . . . . . . . . . . . . . 125 Internet SCSI - iSCSI . . . . . . . . . . . . . . . . . . . . . . . 127

7.3

Sistemas de Arquivos Distribudos . . . . . . . . . . . . . . . . . . . 130 7.3.1 7.3.2 7.3.3 Conceitos Bsicos . . . . . . . . . . . . . . . . . . . . . . . . . 130 Servios Oferecidos pelos SADs . . . . . . . . . . . . . . . . 133 Algumas Caractersticas Desejadas em SADs . . . . . . . . . 137
PGINA XVII

VERSAO

1.0

G UIA DE C LUSTER

SUMRIO

7.3.4 7.3.5 7.3.6 7.3.7 7.4

Network File System - NFS . . . . . . . . . . . . . . . . . . . 146 Andrew File System - AFS . . . . . . . . . . . . . . . . . . . . 150 Constant Data Availability - CODA . . . . . . . . . . . . . . 154 Lustre . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 158

Sistemas de Arquivos Paralelos . . . . . . . . . . . . . . . . . . . . . 159 7.4.1 7.4.2 Parallel Virtual Filesystem Version 1 - PVFS . . . . . . . . . . . 159 Parallel Virtual Filesystem Version 2 - PVFS2 . . . . . . . . . . 163

8 Cluster de Aplicao 8.1

169

Linux Virtual Server - LVS . . . . . . . . . . . . . . . . . . . . . . . . . 170 8.1.1 8.1.2 8.1.3 8.1.4 Nomenclatura e abreviaes . . . . . . . . . . . . . . . . . . 171 Tipos de Cluster LVS . . . . . . . . . . . . . . . . . . . . . . . 172 Algoritmos de escalonamento . . . . . . . . . . . . . . . . . . 176 Casos de uso de LVS . . . . . . . . . . . . . . . . . . . . . . . 180

8.2

Cluster Tomcat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181 8.2.1 8.2.2 Balanceamento de carga . . . . . . . . . . . . . . . . . . . . . 184 Compartilhamento de sesses . . . . . . . . . . . . . . . . . . 187

8.3 8.4

Heartbeat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 188 Zope Cluster . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189

9 Cluster de Banco de Dados


VERSAO

194
PGINA XVIII

1.0

G UIA DE C LUSTER

SUMRIO

9.1 9.2 9.3

Banco de Dados Distribudos . . . . . . . . . . . . . . . . . . . . . . 199 Replicao de Banco de Dados . . . . . . . . . . . . . . . . . . . . . 199 PostgreSQL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 201 9.3.1 9.3.2 9.3.3 PGpool . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 201 PGcluster . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 204 Slony . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 207

9.4

Mysql . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 208 9.4.1 9.4.2 Replicao em MySQL . . . . . . . . . . . . . . . . . . . . . . 208 MySQL Cluster . . . . . . . . . . . . . . . . . . . . . . . . . . 211

9.5

Middlewares independentes de Banco de Dados . . . . . . . . . . . . 212 9.5.1 9.5.2 Middleware Sequoia . . . . . . . . . . . . . . . . . . . . . . . 212 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

G UIA DE C LUSTER

SUMRIO

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 Paralelismo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 239 11.2.1 Relao entre Algoritmos e Arquiteturas Paralelas . . . . . . 240 11.2.2 Propriedades de um Modelo de Programao para o Processamento 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 Totalmente Implcita . . . . . . . . . . . . . . . . . . . . . . . . 249 11.3.2 Modelos com Assinalamento do Paralelismo Explcito . . . 254 11.3.3 Modelos com Assinalamento e Decomposio do Paralelismo Explcitos . . . . . . . . . . . . . . . . . . . . . . . . . . 257 11.3.4 Modelos com Assinalamento, Decomposio e Mapeamento 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 Totalmente Explcita . . . . . . . . . . . . . . . . . . . . . . . . . 262
VERSAO

1.0

PGINA XX

G UIA DE C LUSTER

SUMRIO

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

G UIA DE C LUSTER

SUMRIO

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

G UIA DE C LUSTER

SUMRIO

IV Apndices
A Licena CC-GNU GPL

350
351

B Marcas Registradas

361

C Lista de Abreviaturas

363

D Tecnologias

368

E Glossrio

371

F O Ambiente LabCluster F.1 F.2 F.3 F.4 F.5

380

Histrico do LabCluster . . . . . . . . . . . . . . . . . . . . . . . . . 381 Misso do LabCluster . . . . . . . . . . . . . . . . . . . . . . . . . . . 383 Descrio do Ambiente LabCluster . . . . . . . . . . . . . . . . . . . 383 Infra-estrutura de Hardware . . . . . . . . . . . . . . . . . . . . . . . 384 Poltica de Utilizao do Ambiente LabCluster . . . . . . . . . . . . 384

G Outros Documentos Produzidos

386

Referncias Bibliogrcas

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 37

3.2 3.3 3.4 3.5

Evoluo da utilizao de S.O. Fonte Top500.org . . . . . . . . . . .

Evoluo da utilizao por segmento de mercado. Fonte Top500.org 38 Esquema do modelo de cluster proposto. . . . . . . . . . . . . . . . Sistema de alta disponibilidade com dois servidores sendo acessados por 4 clientes. Um dos servidores Primrio(ativo) e outro Secundrio(passivo) . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

54

5.1

Relao Carga X Custo de investimento, para plataforma Baixa X Alta . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

75

6.1
VERSAO

Blocos bsicos dos computadores seqenciais . . . . . . . . . . . . .

79

1.0

PGINA XXIV

G UIA DE C LUSTER

LISTA DE FIGURAS

6.2 6.3

Arquitetura genrica de multiprocessador de memria . . . . . . . Arquitetura genrica de multiprocessador de memria compartilhada . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Arquitetura genrica sncrona matricial . . . . . . . . . . . . . . . .

81

83 86

6.4 6.5 6.6 6.7 6.8 6.9

Alternativas para conectar o processador a rede de interconexo . . 102 Topologia em barramento . . . . . . . . . . . . . . . . . . . . . . . . 104 Topologia em malha . . . . . . . . . . . . . . . . . . . . . . . . . . . 104 Topologia em hipercubo . . . . . . . . . . . . . . . . . . . . . . . . . 105 Topologia em rvore . . . . . . . . . . . . . . . . . . . . . . . . . . . 106

6.10 Esquema de funcionamento de um sistema VRRP . . . . . . . . . . 115

7.1 7.2

Viso do nvel conceitual de funcionamento do DRBD. . . . . . . . 123 Fluxo de intercomunicao entre as camadas dos dispositivos Linux - repare que o DRBD no tem como noticar o mdulo do sistema de arquivos - mas o oposto ocorre. . . . . . . . . . . . . . . 124 Exemplo de cenrio GNBD . . . . . . . . . . . . . . . . . . . . . . . 127 Exemplo de uma rvore de diretrios . . . . . . . . . . . . . . . . . 131 Estrutura de diretrios distribuda . . . . . . . . . . . . . . . . . . . 136 Volumes, VSGs e AVSGs . . . . . . . . . . . . . . . . . . . . . . . . . 155 Viso Geral do PVFS . . . . . . . . . . . . . . . . . . . . . . . . . . . 161 Clientes acessando o PVFS . . . . . . . . . . . . . . . . . . . . . . . . 162 Fluxo de dados pelo kernel . . . . . . . . . . . . . . . . . . . . . . . 162
PGINA XXV

7.3 7.4 7.5 7.6 7.7 7.8 7.9


VERSAO

1.0

G UIA DE C LUSTER

LISTA DE FIGURAS

8.1 8.2 8.3 8.4 8.5 8.6 8.7 8.8 8.9

Esquema geral de um Linux Virtual Server . . . . . . . . . . . . . . 171 LVS-NAT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173 LVS-DR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175 LVS-Tun . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176 Viso geral de um cluster Tomcat . . . . . . . . . . . . . . . . . . . . 183 Balanceamento de carga via DNS Round-Robin . . . . . . . . . . . . 185 Balanceamento de carga via Apache mod_jk . . . . . . . . . . . . . 186 DNS round-robin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 191 ZEO/ZODB + LVS+OCFS2 . . . . . . . . . . . . . . . . . . . . . . . 193

9.1 9.2 9.3 9.4 9.5 9.6 9.7 9.8 9.9

Arquitetura PG-pool . . . . . . . . . . . . . . . . . . . . . . . . . . . 204 Sistema de balanceamento de carga . . . . . . . . . . . . . . . . . . . 205 Sistema de alta disponibilidade . . . . . . . . . . . . . . . . . . . . . 206 Princpio do Sequoia . . . . . . . . . . . . . . . . . . . . . . . . . . . 215 Exemplo de RAIDb-0 . . . . . . . . . . . . . . . . . . . . . . . . . . . 217 Exemplo de RAIDb-1 . . . . . . . . . . . . . . . . . . . . . . . . . . . 218 Exemplo de RAIDb-2 . . . . . . . . . . . . . . . . . . . . . . . . . . . 219 Exemplo de RAIDb-1-0 . . . . . . . . . . . . . . . . . . . . . . . . . . 220 Exemplo de RAIDb-0-1 . . . . . . . . . . . . . . . . . . . . . . . . . . 220

11.1 Modelo Para Computao Paralela . . . . . . . . . . . . . . . . . . . 244


VERSAO

1.0

PGINA XXVI

G UIA DE C LUSTER

LISTA DE FIGURAS

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 Afnity comparado com outras heursticas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 311
VERSAO

1.0

PGINA XXVII

G UIA DE C LUSTER

LISTA DE FIGURAS

13.17Sumrio do desperdcio de recursos por Storage Afnity 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 6.2

Formas bsicas de tolerncia falhas. Fonte DANTAS [136] . . . . Nveis de Alta Disponibilidade . . . . . . . . . . . . . . . . . . . . .

93 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 paralelas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 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 implementaes 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 Disponibilidade, 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 computadores convencionais (estaes de trabalho), ou seja, vrios computadores comuns ligados em rede que se comunicam e trabalham como se fosse uma mquina de grande porte, com capacidade de suportar um ambiente de grande demanda computacional.
1

Estes dispositivos tambm podem funcionar separadamente


1.0 PGINA XXXI

VERSAO

G UIA DE C LUSTER

1.2 - P BLICO

O Grid Computacional (The Computational Grid), uma rede de execuo de aplicaes paralelas em recursos geogracamente dispersos e pertencentes a mltiplas 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 desempenho). Os termos Software de Fonte Aberta (Open Source Software) e Software Livre (Free Software) tem seus defensores e suas diferenas conceituais e jurdicas. Neste trabalho, 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 Licena 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 poderes: 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 Gerncia 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 documento, 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 Tecnologia 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 colaboradores: 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 relacionadas 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 nal deste perodo o domnio da tecnologia foi apontado como um fator determinante, dentre outros, para a superao do problema de gerao de dcits persistentes, tornando o clima propcio para a intensicao dos investimentos pblicos em informtica, ao lado de uma poltica protecionista indstria nacional(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, almejando a utilizao de tecnologias consideradas na poca de ponta", o Estado Brasileiro acabou por se tornar, de certa forma, um vido consumidor tecnolgico. Um grande parque computacional heterogneo foi estruturado baseado no paradigma da computao de grande porte, num momento em que as tecnologias computacionais eram desenvolvidas por empresas multinacionais e, posteriormente 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 transaes simultneas e alta disponibilidade dos servios esto diretamente relacionadas 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 processo de negociao do governo para a aquisio de novos equipamentos e servios uma atividade limitada e desproporcional. Com poucas empresas capazes de produzir e/ou prestar os servios para o atendimento das demandas e algumas 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 computacional, onde as tecnologias de computao de grande porte possuem um elevado 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 fragmentada e isolada, tendo criado, diversas ilhas tecnolgicas e sistemas sem padres transversais, o que diculta 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 prestao 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 cobrana da sociedade brasileira pela transparncia e otimizao do uso de recursos pblicos, bem como, o combate corrupo e fraude so cada vez mais inuentes, aumentando a necessidade de integrao dos sistemas e o poder computacional 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 Desburocratizao3 at a Reforma Administrativa [175] , no foram capazes de atingir 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, dicultado ou inviabilizado no paradigma da computao de grande porte, seja por conta dos recursos e investimentos necessrios para se estabelecer esse processo, seja pela diculdade 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 sustentveis 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 entre 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: Pehttp://www.serpro.gov.br/.

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 benecirios/ms. Maiores informaes em: http://www.dataprev.gov.br. 3 O Programa Nacional de Desburocratizao da Secretaria de Gesto do Ministrio do Planejamento, Oramento e Gesto, Decreto no 3335, de 11 de janeiro de 2000, que previa: Desburocratizar a Administrao Pblica fundamental para preparar o pas aos novos desaos. imperativo que o Estado se mostre gil e competente no atendimento de seus cidados, como tambm imprescindvel que esses no se intimidem ao procurar os servios pblicos e que tenham certeza da boa qualidade e da ecincia 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 Cientca (LNCC), Google, HP, IBM, Sun, Itautec, Departamento de Defesa Americano (DOD), National Center for Supercomputing Applications (NCSA), entre outros. 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 distribuda e de computao de grande porte. Na computao distribuda o importante 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 especco, tolerante a falhas e com redundncia. Atravz da utilizao de hardware padro x86 (pc) e sem a necessidade de redundncias e dispositivos especiais no hardware possvel construir sistemas com hardware de baixo custo, compatvel com padres abertos e internacionais, reduzindo 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 m, 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

G UIA DE C LUSTER

2.1.1 - A S OCIEDADE DA I NFORMAO E A I NOVAO T ECNOLGICA

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 princpios e metas relativos preservao de nossa identidade cultural, fundada na riqueza da diversidade; a sustentabilidade de um padro de desenvolvimento que respeite as diferenas 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 identicou 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 utilizao 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

G UIA DE C LUSTER

2.1.1 - A S OCIEDADE DA I NFORMAO E A I NOVAO T ECNOLGICA

A sociedade da informao no um modismo. Representa uma profunda mudana na organizao da sociedade e da economia, havendo quem a considere um novo paradigma tcnico-econmico. um fenmeno global, com elevado potencial transformador das atividades sociais e econmicas, uma vez que a estrutura 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 inovaes, 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 benefcios 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 conhecimento. 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 desao, portanto, duplo: superar antigas decincias 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 geogrca e da situao social do cidado, garantindo nveis bsicos de servios, estimulando a interoperabilidade de tecnologias e de redes. A sociedade civil deve zelar para que o interesse pblico seja resguardado, buscando organizar-se para monitorar e inuenciar, sistematicamente, os poderes pblicos e as organizaes privadas (Livro Verde [135]). Assim desaos da sociedade da informao demandam cada vez mais uma grande quantidade de recursos computacionais, devido a ampla difuso de servios e aplicaes ao pblico geral, em especial aos cidados. Neste contexto, o Livro Verde" aponta uma srie de tecnologias consideradas chave para o desenVERSAO

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, Previso 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 simultneos 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 governamentais), o acesso direto aos governantes e representantes eleitos. O setor governamental o principal indutor de aes estratgicas rumo Sociedade da Informao. Primeiramente, porque cabe ao governo denir o quadro regulatrio dentro do qual projetos e iniciativas concretas podero ser formuladas. Segundo, porque como regra o governo o maior comprador/contratador de bens e servios em tecnologias de informao e comunicao em um pas. Assim, 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 ecincia e transparncia de suas prprias aes"(Livro Verde [135]).

2.2 Governo Eletrnico Brasileiro


O Governo Eletrnico foi concebido como instrumento de transformao da sociedade 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 novos paradigmas que mereciam igualmente a ateno do Governo Eletrnico. Assim, em suas diretrizes, foram explicitados:

[...] O papel do Estado neste mundo em transformao continua fundamental 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 decisrio 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 eciente na prestao de servios aos seus cidados.(Vide stio do Governo Eletrnico [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 especcos no mbito do Comit Executivo do Governo Eletrnico: Implementao de Software Livre, Incluso Digital, Integrao de Sistemas, Sistemas Legados e Licenas de Software, 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 estruturadas 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 independncia, 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 Governo Eletrnico passou a ser realizada segundo sete princpios, que foram assim concebidos5 :

[...] como referncia geral para estruturar as estratgias de interveno, adotadas 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 polticas, sistemas, padres e normas. 7. Integrao das aes de Governo Eletrnico com outros nveis de governo e outros poderes.

Nesse novo contexto, a atuao do Governo Eletrnico pretende melhorar a prestao de servios aos cidados, com aumento da transparncia e diminuio da burocracia, contribuindo para a democratizao do processo decisrio, a efetividade das aes governamentais e a promoo da incluso digital. Para dar suporte a toda demanda computacional que gerada por esses princpios, 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 conana e de baixo custo.
5 Ocinas de Planejamento Estratgico. RELATRIO CONSOLIDADO. Comit Executivo do Governo 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 ecincia da Administrao Pblica no contexto da Sociedade da Informao, articulada s aes estabelecidas para implantao do Governo Eletrnico, o Governo brasileiro elaborou um conjunto de premissas, polticas e especicaes tcnicas regulamentadoras para utilizao da Tecnologia da Informao e da Comunicao, denominada Arquitetura e-PING Padres de Interoperabilidade6 de Governo Eletrnico". A Arquitetura e-PING dene um conjunto mnimo de premissas, polticas e especicaes tcnicas, que regulamentam a utilizao da Tecnologia de Informao 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; Segurana; 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 Comunicao (TIC) que se preste como o alicerce para a criao dos servios de governo 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 especicaes claramente denidas para interoperabilidade e gerenciamento 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, reutilizao e intercmbio de recursos tecnolgicos."

A e-PING apresenta, em cada um dos seus segmentos, polticas tcnicas norte6 Os conceitos de interoperabilidade adotados nesta arquitetura esto evidenciados no Documento de Referncia, disponvel em http://www.eping.e.gov.br.

VERSAO

1.0

PGINA 11

G UIA DE C LUSTER

2.2.2 - PADRES DE I NTEROPERABILIDADE DE G OVERNO E LETRNICO

adoras para estabelecimento das especicaes 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 desenvolvimento 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 administrao pblica devero estar alinhados com as principais especicaes 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 Eletrnico - e-PMG, baseado em padres internacionalmente aceitos; Escalabilidade: as especicaes selecionadas devero ter a capacidade de atender alteraes de demanda no sistema, tais como, mudanas em volumes 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 necessidades 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 dene que, sempre que possvel, sero adotados padres abertos nas especicaes tcnicas. Padres proprietrios so aceitos, de forma transitria, mantendo-se as perspectivas de substituio assim que houver condies de migrao. Sem prejuzo 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 preferenciais.

Em sua segunda parte, Especicao Tcnica dos Componentes da e-PING", vrios pontos so levantados de interesse para novos projetos de sistemas de informtica e informao. Principalmente no que se pode caracterizar como computao distribuda, com a utilizao de Web Services e de Arquitetura Orientada Servios (SOA).
VERSAO

1.0

PGINA 12

G UIA DE C LUSTER

2.2.2 - PADRES DE I NTEROPERABILIDADE DE G OVERNO E LETRNICO

Com a utilizao de Web Services para a interligao, integrao e interoperabilidade 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 anteriormente." 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 especicao do servio dever utilizar a linguagem WSDL."

Na e-PING, Web Service"est denido como:

Os Web Services so aplicaes de software, identicadas por uma URI (Uniform Resource Identier), cujas interfaces e ligaes so capazes de serem denidas, 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 governo, implementados em diferentes tecnologias, s vezes de forma simultnea 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 Linguagens 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 especicaes: Protocolo de troca de informaes: SOAP v1.2, como denido 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:Especicao UDDI v3.0.2 (Universal Description, Discovery and Integration) denida pela OASIS; Linguagem de denio do servio: WSDL 1.1 (Web Service Description Language) como denido pelo W3C.

Um outro fator importante observado na sesso de Integrao para Governo Eletrnico, onde se dene 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 polticas 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 instrumentos estratgicos de articulao e gesto de polticas pblicas porque possibilitam a produo compartilhada e colaborativa de conhecimento, assegurando
VERSAO

1.0

PGINA 14

G UIA DE C LUSTER

2.2.3 - A S D IRETRIZES DO G OVERNO E LETRNICO E O S OFTWARE L IVRE

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 losoa do Software Livre surge como oportunidade para disseminao do conhecimento e nova modalidade de desenvolvimento tecnolgico, 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 principalmente pelos princpios de Impessoalidade, Ecincia e Razoabilidade7 , visando melhoria na qualidade dos servios prestados e promoo dos desenvolvimentos tecnolgico e social. Portanto, o Estado se benecia 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, possibilitamos a integrao das polticas de modernizao administrativa, incluso social baseadas na Tecnologia da Informao e no desenvolvimento industrial. A questo do Software Livre est contextualizada em amplo cenrio integrado, composto por aes de desenvolvimento tecnolgico, insero adequada do Pas na chamada Sociedade da Informao, promoo da cidadania, incluso digital e racionalizao de recursos. "

O Guia Livre"dene como principais razes para o uso de Software Livre:


7 O artigo 37 da Constituio da Repblica apresenta os Princpios Basilares da Administrao Pblica: legalidade, impessoalidade, moralidade, publicidade e ecincia. O princpio da razoabilidade possui fundamentao implcita, sendo evidenciado em algumas Constituies Estaduais.

VERSAO

1.0

PGINA 15

G UIA DE C LUSTER

2.2.3 - A S D IRETRIZES DO G OVERNO E LETRNICO E O S OFTWARE L IVRE

Necessidade de adoo de padres abertos para o Governo Eletrnico (eGov); Nvel de segurana proporcionado pelo Software Livre; Eliminao de mudanas compulsrias que os modelos proprietrios impem periodicamente a seus usurios, em face da descontinuidade de suporte 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 estimulando 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, otimizao de processos, reutilizao de cdigos e adoo de arquiteturas computacionais abertas. O compartilhamento da informao e a adoo do software livre por muitos rgos 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 contribui para manter o software vivo, corrigindo seus defeitos, aperfeioando seu funcionamento, introduzindo inovaes e fazendo com que o produto se consolide mais robusto e a cada dia se torne mais conhecido por um conjunto maior de prossionais 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 software livre tambm possibilita ao cidado o direito de acesso aos servios pblicos e ao conhecimento sem obrig-lo a usar uma plataforma especca. 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 desaos de utilizao de software livre no desenvolvimento de solues 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 perspectiva 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 utilizao 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 informtica pblica, como instrumento de melhoria da qualidade de servios, competividade e ecincia; estmulo ao desenvolvimento de tecnologias nacionais e a Poltica Nacional de Informtica;
8

http://www.top500.org/stats
1.0 PGINA 17

VERSAO

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 redes computacionais do governo federal. O presente documento apresenta as possibilidades, tecnologias e cenrios de utilizao de cluster e grid no Governo Federal, tendo como objetivo ampliar seu uso interno no governo de maneira a melhor atender as novas demandas computacionais da Sociedade da Informao que, segundo a diretriz de modernizao da mquina pblica, encontram-se cada vez mais internalizadas no governo brasileiro.

2.3 As Novas Demandas Computacionais


As atividades econmicas que utilizam redes eletrnicas como plataforma tecnolgica tm sido denominadas negcios eletrnicos (e-business). Essa expresso engloba os diversos tipos de transaes comerciais, administrativas e contbeis, 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 interagem entre si de vrias maneiras. H cinco tipos de relaes entre esses atores em aplicaes governamentais:

B 2B (business-to-business): transaes entre empresas, exemplos: EDI, portais verticais de negcios; B 2C /C 2B (business-to-consumer/consumer-to-business): transaes entre empresas e consumidores, exemplos: lojas e shoppings virtuais;
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

G UIA DE C LUSTER

2.3 - A S N OVAS D EMANDAS C OMPUTACIONAIS

B 2G/G2B (business-to-government/government-to-business): transaes envolvendo empresas e governo, exemplos: EDI, portais, compras. Corresponde a aes do Governo que envolvem interao com entidades externas. O exemplo mais concreto deste tipo a conduo de compras, contrataes, licitaes, etc, via meios eletrnicos; C 2C (consumer-to-consumer): transaes entre consumidores nais (exemplos: sites de leiles, classicados on-line); G2C /C 2G (government-to-consumer/consumer-to-government): transaes envolvendo governo e o cidado (consumidores nais dos servios do Governo), exemplos: pagamento de impostos, servios de comunicao). 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 horizontalmente, exemplo: no nvel Federal, ou dentro do Executivo; ou verticalmente, 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 usualmente 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 funes, etc.;


VERSAO

1.0

PGINA 19

G UIA DE C LUSTER

2.3 - A S N OVAS D EMANDAS C OMPUTACIONAIS

tm especicao dinmica, isto , se modica 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 pelas tecnologias adequadas e compatveis, seguindo as diretrizes de Governo Eletrnico e os padres de interoperabilidade j denidos pela e-PING. A adoo de padres tcnicos e sua institucionalizao so fundamentais para assegurar que aplicaes governamentais, mesmo resultando de uma mirade de iniciativas 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 concebidas na forma de processos lineares com viso demasiadamente simplista, com cronogramas irrealistas e sem um plano de evoluo de longo prazo. Os desaos da Sociedade da Informao" apresentados no Livro Verde, a insero do Brasil neste processo Global, a disseminao do acesso a Internet e as pesquisas do meio acadmico, convergiram em novas possibilidades de aplicao 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 melhoria da qualidade dos servios prestados aos cidados, bem como para o aumento 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 sistemas de inteligncia capazes de transformar o imenso volume de dados atual em informao til e agregada, atravs da utilizao de sistemas de Business InteliVERSAO

1.0

PGINA 20

G UIA DE C LUSTER

2.3 - A S N OVAS D EMANDAS C OMPUTACIONAIS

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 cidados 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 reetem-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 registros; 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 caractersticas 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 nanceira dos investimentos pblicos e a crescente necessidade de racionalizao do uso de recursos pblicos em TI, que muitas vezes impossibilitam o desenvolvimento ou implementao de um novo sistema diante do custo total de propriedade envolvido na aquisio de hardware e software para computao de grande porte.
VERSAO

1.0

PGINA 21

G UIA DE C LUSTER

2.3 - A S N OVAS D EMANDAS C OMPUTACIONAIS

Diculdade de aumentar ou diminuir a capacidade computacional de acordo com a demanda atual de cada instituio. Normalmente, servidores de computao de grande porte possuem uma capacidade mxima de expanso limitada por srie ou modelo do equipamento. Quando uma instituio 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 equipamento 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 componentes. 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, inuenciada pela reduo da competio entre empresas no mercado. Sistemas e hardwares heterogneos: existe no governo um parque computacional extremamente heterogneo. Encontram-se em uso hardwares e softwares dos mais variados fornecedores, muitas vezes incompatveis entre si, devido ao emprego de padres fechados ou arquiteturas proprietrias. Diculdade de integrao e interoperabilidade entre os sistemas devido abundncia de padres proprietrios, segmentados e divergentes, conjugados com a falta de padres abertos. A Administrao Pblica obrigada a construir ou adquirir brokers10 , que funcionam como pontes entre tecnologias incompatveis, envolvendo muitas vezes o pagamento de licenas para desenvolvimento das arquiteturas proprietrias utilizadas. Estes fatores dicultam 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 objetivando maior transparncia nas aes governamentais, otimizao do uso de recursos pblicos, construo de processos democrticos entre governo, empresas e cidados. Alguns exemplos so:
10

Midlerware de integrao e comunicao.


1.0 PGINA 22

VERSAO

G UIA DE C LUSTER

2.3 - A S N OVAS D EMANDAS C OMPUTACIONAIS

Sistema eleitoral com votao e apurao atravs da utilizao de urnas eletrnicas; Portal de Compras Governamentais11 e o Sistema Integrado de Administrao de Servios Gerais - SIASG, que so um conjunto de ferramentas para operacionalizar internamente o funcionamento sistmico das atividades 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 arrecadao fazendria esto disponveis na Internet. A declarao de imposto de renda de pessoa fsica disponibilizada por meio eletrnico atravs da Internet 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 interoperao 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 pblicos 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
http://www.comprasnet.gov.br O Sistema Integrado de Administrao de Servios Gerais - SIASG, um conjunto informatizado de ferramentas para operacionalizar internamente o funcionamento sistmico das atividades inerentes ao Sistema de Servios Gerais - SISG, quais sejam: gesto de materiais, edicaes pblicas, veculos ociais, comunicaes administrativas, licitaes e contratos, do qual o Ministrio 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 ecincia do sistema de aquisies eletrnicas 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 conseguinte, 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.
12
VERSAO

11

1.0

PGINA 23

G UIA DE C LUSTER

2.3 - A S N OVAS D EMANDAS C OMPUTACIONAIS

uxo 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 metodologia e arquitetura padronizadas que garantem a interoperao transparente 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 qualidade de dados permite limpar, padronizar e cruzar os cadastros que utilizam dados como nome, data de nascimento, nome de pai e me e nmero de documento de identicao.Tambm possibilita identicar erros de digitao e fazer comparaes por similaridade. Reconhece, por exemplo, a existncia de dois cadastros para uma nica pessoa que possui um registro 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 diferenas 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 interao desse Poder com a sociedade. Os meios utilizados so as novas tecnologias de informao (Internet, videoconferncia e transmisso de dados) que permitem a comunicao e a troca de experincias entre as Casas Legislativas e os legisladores e entre o Poder Legislativo e o pblico, visando aumentar a participao da populao. Em funo das nalidades do Programa o cadastro no Portal Interlegis aberto a qualquer pessoa, dando a oportunidade a essas pessoas adicionarem contedo ao stio (pginas, 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 baseados 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 utuantes, ou seja, durante um momento convivem com pouca ou nenhuma carga de processamento e em outro momento especco possuem uma elevada carga de processamento. Um exemplo deste perl 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 nal deste perodo, maior a quantidade de declaraes e, conseqentemente, a capacidade computacional 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 diculdade 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, devido s caractersticas de demandas utuantes de processamento desses sistemas governamentais. Em resumo, a administrao alocar na maior parte do tempo recursos nanceiros 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 resoluo desse desao de computao sob demanda, minimizando a capacidade de processamento ociosa existente dentro da administrao pblica, bem como a alocao de recursos nanceiros 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 comum. 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 computacional 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 processamento e execuo de sistemas internos, e as universidades e centros de pesquisa atravs de projetos de pesquisa cientca [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 nalidades genricas criado em 1997. Nestes projetos so utilizados os ciclos ociosos de processamento de mquinas interligadas na internet, no dedicadas exclusivamente rede de processamento e dispersas 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 desenvolvidas em universidades brasileiras que poderiam ser utilizadas para aproveitar a capacidade de processamento ocioso das milhares de estaes de trabalho do governo brasileiro. Algumas dessas solues so: o vCluster[147] e o Ourgrid[62], desenvolvidos respectivamente pela Pontifcia Universidade Catlica 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 denida 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 processamento 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 distribuda. So computadores que geralmente ocupam um grande espao fsico e necessitam de ambiente especial para seu funcionamento. Os mainframes so capazes de realizar operaes em grande velocidade e sobre um volume muito grande de dados. Os mainframes nasceram em 1946 e foram constantemente aperfeioados. 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 cientcas e militares. Este termo geralmente confundido com cluster, um tipo de supercomputador criado a partir da cooperao de vrios computadores convencionais. Os primeiros 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 genericamente 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 decorrente da utilizao da computao de grande porte. A rea mais escura reete 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
1.0 PGINA 28

VERSAO

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 processamento superior exigncia inicial. Essa medida justica-se pelo j citado alto custo do equipamento envolvido: uma vez que recursos nanceiros sero empregados na utilizao de mquinas multiprocessadas, interessante que essas mquinas operem no maior tempo possvel. Dessa forma, para satisfazer a demanda de processamento destacada em C1 , adquire-se uma soluo com capacidade C2 , superior, que ir garantir o funcionamento do ambiente at que a exigncia de processamento atinja seu limite mximo. Na gura 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 necessrio a realizao de um upgrade, que geralmente caracteriza-se pela substituio do equipamento original por um novo, ou pela incorporao de novo hardware ao equipamento original. Qualquer uma das alternativas exigir elevado custo nanceiro. Assim, passa-se utilizao de um equipamento com capacidade de processamento C3 , para novamente garantir a operacionalizao do ambiente por mais um perodo de tempo (T 1 at T 2), inaugurando um ciclo consde 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 diculdade de dimensionamento do ambiente, conforme representado pela rea mais clara na Figura 2.1 e normalmente quando atingem a carga mxima, sofrem diculdades de expanso do hardware(capacidade de processamento). Portanto, em ltima instncia, a Administrao aloca recursos nanceiros 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 processamento 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 dimensionamento 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 distribudo.

mais recentes e tenham arquitetura computacional mais moderna, alguns especialistas 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 arquiteturas distribudas podem ser encontradas nos captulos: Cluster de Armazenamento (captulo 7), Cluster de Aplicao (captulo 8), Cluster de Banco de Dados (captulo 9), Cluster de processamento (captulo 10), Grid computing (captulo 13) e Virtualizao de Recursos (captulo 14). A tabela 2.1 apresenta as principais diferenas entre as duas abordagens tecnolgicas tratadas na seo 2.4. Grande Porte - Alto custo de implantao; - Dependncia nico; de fornecedor Cluster e Grid - Baixo custo de implantao; - Independncia de fornecedores facilidade de negociao; - Utilizao de hardware comum padro PC; - Baixo custo de manuteno; - Facilidade de redimensionamento do ambiente; - Maximizao da capacidade de processamento; - Baixo custo total de propriedade; - Tecnologia inovadora.

- Utilizao de hardware especco; - Alto custo de manuteno; - Diculdade de redimensionamento do ambiente; - Utilizao parcial da capacidade de processamento; - Grande custo total de propriedade; - Tecnologia estabelecida no mercado.

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, baseada na utilizao de terminais burros que servem apenas como meio de visualizao de aplicaes, softwares e dados que encontram-se no computador central. Os recursos computacionais de processamento e armazenamento utilizados nesta gerao so exclusivamente do computador que hospeda 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 executadas 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 executadas 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 multicamadas 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 computacionais alocados em um pool virtual, de forma que o cliente utiliza capacidade 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 estruturais 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 tecnologias 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 gestores dos sistemas realizar as devidas anlises para vericar 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 utilizao 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, engenharia, 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 gura 3.1 mostra a evoluo percentual das arquiteturas de sistemas de alto desempenho no mundo, onde os sistemas classicados como Clusters j so responsveis por 72, 80% dos ambientes de supercomputao classicados na lista. Os dados so da organizao 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 gura 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 observado 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, Google, 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 corporativos que utilizam as mquinas de maior capacidade computacional do mundo, a gura 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


1.0 PGINA 38

VERSAO

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 desaos 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 tcnicas:

Utilizao de hardware padro de mercado em sistemas crticos atravs da transferncia do gerenciamento das funes de alta disponibilidade, tolerncia falhas e balanceamento de carga do hardware para o software. Diminuindo a necessidade de hardware especializado, aumentando a concorrncia entre as empresas fornecedoras e propiciando ao governo a independncia 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 nestas tecnologias, em oposio a sistemas em computao de grande porte que utilizam, em sua grande parte, tecnologias proprietrias e padres fechados. 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 computacionais. 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 endereo: 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 computadores 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 exemplicada 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 externamente 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, Balanceamento de Carga, Alta Performance.

3.2.2 Camada de Banco de Dados


Esta camada responsvel pelos bancos de dados que so acessados pelos servios 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 Replicao 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 servidores 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, Integridade dos Dados, Alta Performance e Arquivos Distribudos.

3.2.4 Diagrama da arquitetura proposta

A gura abaixo apresenta um diagrama da arquitetura proposta na seo 3.2

Balanceamento Internet de carga

Balanceamento de carga Internet

Cluster principal

Cluster espelho

Aplicaao

Switch

Aplicaao

Switch

Banco de dados

Switch

Banco de dados

Balanceamento de carga

Switch

Link de backup

Balanceamento de carga

Armazenagem

Switch

Armazenagem

Figura 3.4: Esquema do modelo de cluster proposto.

VERSAO

1.0

Switch

Switch

Switch

Switch

Switch

Switch

Switch

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 denidos 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 armazenamento em Cluster, ou. Camada de aplicao atravs de mquina RISC grande porte e/ou Mainframe, 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 sistemas computacionais, da mesma forma que qualquer outra mudana tecnolgica. Os gestores, juntamente com os tcnicos, devero denir 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 distintas. Entretanto, existem necessidades ou caractersticas que so comuns a maioria 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 disponibilidade 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: Condencialidade: o acesso a informao dever ser realizado to somente s entidades autorizadas, ou seja, quelas legitimamente denidas pelo proprietrio da informao. Integridade: a informao manipulada deve manter todas as caractersticas originais estabelecidas pelo proprietrio da informao, incluindo controle de mudanas e garantia do seu ciclo de vida (nascimento, manuteno, arquivamento e destruio). Disponibilidade: a informao deve estar sempre disponvel para o uso legtimo, ou seja, por aqueles usurios autorizados pelo proprietrio da informao. Utilizao de Padres Abertos: crescente necessidade de utilizao de padres 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 dene os padres adotados, recomendados e em transio que devero ser utilizados pelo governo brasileiro. Aderncia Legislao: sistemas e aplicaes de governo necessariamente devem estar de acordo com a legislao vigente no pas.

A denio 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 denir 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


1.0 PGINA 44

VERSAO

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 sistemas 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 nalidades, sendo necessrio realizar uma anlise, e conseqente vericao 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 ): Sistema responsvel pela gerao e processamento da folha de pagamentos dos funcionrios da administrao pblica federal. Atualmente, este sistema funciona em um computador de grande porte que centraliza o processamento de todas as folhas de pagamento da administrao pblica federal. 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 poderia 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 mainfraime utilizado atualmente por este sistema. Sistema Integrado de Administrao Financeira do Governo Federal - SIAFI4 : O SIAFI o principal instrumento utilizado para registro, acompanhamento e controle da execuo oramentria, nanceira 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 software livre e tecnologia de Cluster de balanceamento de carga.
3 4

http://www.siapenet.gov.br http://www.tesouro.fazenda.gov.br/SIAFI/
1.0 PGINA 45

VERSAO

G UIA DE C LUSTER

3.3.1 - C ENRIO - A PLICAES WEB

Para efeitos didticos e de esclarecimento das possibilidades de utilizao de tecnologias de Cluster e Grid no Governo Federal, sero denidas alguns cenrios bsicos diferentes onde sero apresentadas caractersticas das aplicaes, demandas computacionais e uma pequena anlise sobre quais tecnologias podero ser utilizadas. Para informaes tcnicas sobre as tecnologias de Cluster e Grid abordadas 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 consultas 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 ininterruptamente, as questes como integridade, condencialidade e autenticidade so essenciais, pois as informaes contidas no portal no devem ser alteradas e disponibilizadas 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

01 02 03 04

Acessos Simultneos 250 350 450 500

Carga Utilizada 50% 70% 90% 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 upgrade 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 servidor 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 processadores ter um desempenho menor que duas mquinas de 4 processadores devido as caractersticas e limitaes fsicas da arquitetura x86_32 e x86_64. Sabese 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 arquitetura x86_32 e x86_64 no ser capaz de atender as necessidades computacionais. 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 alguns problemas tais como: alto custo, dependncia tecnolgica e de fornecedor e conseqente diculdade de administrar o ambiente de TI. Para se realizar a ampliao da capacidade computacional de acordo com a segunda 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 balanceamento 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 mquinas:


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 apenas 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 requisio de um usurio para uma mquina defeituosa. Uma tecnologia amplamente 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 captulo 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. Especicamente para o setor pblico, a produo de conhecimento a partir das bases de dados propicia melhor suporte tomada de deciso, tendo por consequncia a promoo da ecincia da administrao. Nesse contexto, a automatizao dos processos de anlise de dados, com a utilizao de software especco, 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 explorao e a anlise, por meio automtico ou semi-automtico, de grandes quantidades de dados, a m de descobrir padres e regras signicativos5 . O processo de minerao de dados tem como principais objetivos descobrir relacionamentos, geralmente no triviais, entre dados armazenados, fornecer subsdios 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 algoritmos de alta complexidade os quais podem realizar tarefas de classicao, estimativa, associao, segmentao ou agrupamento de informaes, com possibilidade de consultas bases de dados no estruturadas. Dessa forma, medida que a base de dados aumenta, as possibilidades de relacionamentos e combinaes de tarefas cresce exponencialmente. Por essa razo, existe o desao de promover um ambiente computacional favorvel 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 algoritmos de manipulao dos dados utilizando-se de tcnicas de explorao de paralelismo e sistemas de processamento distribudo de alto desempe5 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 nalidade 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 questes so obtidas atravs da utilizao de tecnologias de banco de dados distribudo, 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 nanciou 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 redistribuio de verso alterada do software. O tamandu um servio web de minerao 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 encontradas na pgina ocial 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 paralela e sistemas de distribuio do processamento em cluster. Alguns exemplos so: aplicaes de processamento cientco, 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 processaVERSAO

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 existentes para utilizar este tipo de cluster, pois a lgica computacional normalmente 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 paralela 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 dependendo do sistema utilizado, teoricamente, se a aplicao capaz de utilizar 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 Kehrrighed. 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, existem muitos casos onde a adaptao do sistema para execuo em um cluster de processamento baseado em bibliotecas de programao paralela pode ser custoso 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 migrao 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 programa 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 nal 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 alteraes 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 justiquem 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 execuo das mais variadas atividades administrativas, nanceiras, de gesto de pessoas e at mesmo de comunicao na maioria das instituies pblicas. Este ambiente, 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 nanceiro para a instituio. Um fator importante a ser levado em considerao na preparao de infraestrutura para qualquer servio ou aplicao o fato de que todo e qualquer hardware, software ou aplicao esto sujeitos a falhas. Sejam por conta de problemas nos componentes eletrnicos, problemas de desenvolvimento do software/aplicao 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 aumentar 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 software, 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 adquiridos 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 sistema 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 alguma 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 gura 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 falhas no servidor primrio, o heartbeat ser responsvel por tomar as aes necessrias 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, servidor 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 primrio e replicadas em seu disco. Recomenda-se utilizar uma soluo baseada em heartbeat+drbd+mon em sistemas 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 dados 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 classicadas em:

Alta Disponibilidade: Nesta categoria encontram-se as tecnologias de replicao e alta disponibilidade. Para replicao normalmente utilizada alguma soluo prpria ou especca 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 recurso 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 tecnologias 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 tecnologia utilizada normalmente em grandes aplicaes transacionais, onde necessrio aumentar a performance e disponibilidade. As solues mais conhecidas so o pgCluster, especco 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.

http://http://pargres.nacad.ufrj.br/.
1.0 PGINA 55

VERSAO

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 Clusters sofre tambm inuncia 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 triviais. Ao considerarmos que toda mudana capaz de modicar o comportamento e as rotinas das pessoas aumenta o grau de diculdade das tarefas, podemos armar 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 instituio a escolher essa nova tecnologia e as melhorias que essa mudana ir ocasionar. Esta uma atividade essencial na chamada Sensibilizao. Adotar uma nova tecnologia, como a de clusters, necessita de um plano de capacitao que contenha prossionais especializados para viabilizar a difuso do conhecimento dessa tecnologia entre os funcionrios da instituio, para que estes aceitem mais facilmente a implantao, absorvam o conhecimento nas regras de negcio do sistema e possam manter todo o ambiente operacional sem a necessidade e a dependncia de agentes externos. Antes da implantao necessrio, identicar os pers 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 possibilidades 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 especialistas 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 exveis como os ambientes acadmicos) aconselhvel se preparar para responder 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 dadas no artigo: Ten Tips for Building Your First High-Performance Cluster" ou em traduo livre Dez macetes para construir seu primeiro Cluster 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 empresariais mais complexas e tecnologias abertas. Algumas caractersticas que devem ser observadas nesse modelo so:

Escalabilidade do ambiente: Capacidade sob demanda para atender os requisitos 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 especcos; Gerenciamento da carga de trabalho, permisso para estabelecer critrios de desempenho para cargas de trabalho especcas com base em suas regras de negcios e ajustar os recursos de processamento para atingir estas metas.

Essas opes no s estimulam a ecincia 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 subutilizao 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 altodesempenho 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 desaos 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


1.0 PGINA 59

VERSAO

G UIA DE C LUSTER

4.3.1 - O QUE DEVE SER OBSERVADO

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

G UIA DE C LUSTER

4.3.1 - O QUE DEVE SER OBSERVADO

Em caso de aplicaes existentes, que se queira portar para este ambiente, pesquise as possibilidades pois, certamente, o porte de aplicaes mais antigas (legados) 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 conhecidas desde o incio do desenvolvimento do projeto, pois estas que indicaro as possveis tecnologias a serem adotadas para se obter uma equalizao de desempenho e custo total de implantao. Ressalta-se que neste momento do projeto no se pode pensar apenas nas capacidades imediatas do sistema. Deve-se tambm 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 poderemos 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 utilizado para vrias outras aplicaes, como plataforma de desenvolvimento de sistemas, testes de conguraes, projeo de estresse de sistemas e homologao de aplicaes, entre muitas outras coisas.
VERSAO

1.0

PGINA 61

G UIA DE C LUSTER

4.3.1 - O QUE DEVE SER OBSERVADO

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 simplicaes, dentre elas: De instalao e de congurao 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 congurao bsica. Assim, deve ser preciso manter poucas peas sobressalentes que podero ser trocadas rapidamente, caso o hardware do equipamento apresente 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 aplicao, uma pelo rewall e proxy; assim a modelagem do hardware para atender as especicidades dos sistemas utilizados no ambiente de extrema importncia. Mais detalhes deste tipo de ambiente pode ser melhor visto na sesso 3.2. Seguindo assim essa caracterstica de camadas de Cluster, cada uma destas tenderia a ter um nico tipo de congurao de hardware.

Sistemas diskless

Sloan, em seu artigo [334], aconselha evitar a utilizao de sistemas que no utilizam disco rgidos; no entanto, a experincia e a evoluo destes sistemas vm mostrando que a sua ecincia 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 vericar os prs e contras de uma implementao baseada em tecnologia sem disco.
VERSAO

1.0

PGINA 62

G UIA DE C LUSTER

4.3.1 - O QUE DEVE SER OBSERVADO

A importncia da rede de comunicaes

Uma reexo tem de ser feita antes de comear a pensar em redes: um dos grandes erros em projetos de Clusters, para qualquer que seja a sua nalidade, acreditar que o processamento, ou alta capacidade de processamento, baseado apenas 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 interfaces 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 especicar 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 especicao do hardware dos ns, certamente, no precisar de coisas como placas de som, aceleradoras 3D, mouses, teclados e monitores. Se estiver comprando os equipamentos, minimizar o hardware pode baixar seu custo total de forma a permitir comprar mais mquinas. Mas existe um limite esta minimizao" das especicaes de hardware, certamente uma placa de vdeo ser necessria no caso de que se precise dar manuteno em alguma mquina, assim como um CD-Rom pode fazer falta para a
VERSAO

1.0

PGINA 63

G UIA DE C LUSTER

4.3.1 - O QUE DEVE SER OBSERVADO

instalao de softwares e do sistema operacional. Portanto, ter esses equipamentos 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 problema, 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, possibilitando assim melhoras na disponibilidade dos sistemas. Se for preciso obter acesso rede do Cluster, este pode ser provido atravs de conexes seguras por um rewall 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 controle de acesso iria muito alm dos rewalls, proxies e servidores de autenticao, mas tambm passaria pelo estabelecimento de conexes seguras e autenticadas, com uso de certicados digitais, entre outras tecnologias.

Use ferramentas de Cluster

A utilizao de ferramentas, que automatizam as tarefas de instalao e administrao 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

G UIA DE C LUSTER

4.3.1 - O QUE DEVE SER OBSERVADO

Ferramentas como o OSCAR3 , Rocks4 e XCAT5 , simplicam a instalao e o gerenciamento de Clusters, neste caso Cluster de processamento de alto desempenho. Qualquer um destes pacotes provavelmente instalar e congurar 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 ca muito evidente quando se comea a pensar na evoluo do Cluster, de como gerenciar toda a necessidade 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 soluo 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 4

Mais informaes podem ser vistas em http://oscar.openclustergroup.org/ 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

G UIA DE C LUSTER

4.3.1 - O QUE DEVE SER OBSERVADO

no caso de expanso ou na troca de todo o Cluster, que boa parte do equipamento 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 executada 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 congurao, rede, dados histricos de trfego, utilizao e principalmente de problemas. Muitas vezes passamos por problemas que j foram resolvidos em ocasies anteriores, 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 prprio Cluster. Deve-se conhecer como as conexes de rede e energia esto feitas, quais as conguraes e todos os detalhes tcnicos da implementao, para ajudar a prever problemas, bem como facilitar em muito o processo de resoluo de qualquer incidente.

Segurana

Muitos projetos no trabalham o suciente 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

G UIA DE C LUSTER

4.3.1 - O QUE DEVE SER OBSERVADO

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 Especicao 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 processos e tecnologias que sero utilizados, uma aplicao bem projetada ter sucesso na sua execuo em um ambiente de Cluster. As aplicaes sero tratadas por grupos especcos: 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

G UIA DE C LUSTER

4.3.1 - O QUE DEVE SER OBSERVADO

Banco de dados

Conhecer bem as demandas de acesso aos dados pelos sistemas que sero executados 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 arquitetura 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 ambientes 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 Paralelo


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 desempenho efetivo (registrado pelos benchmarks tradicionais, tais como MIPS, MFLOPS, SPECmarks) no ir crescer na mesma razo do clock. Outros aspectos precisariam acompanhar o crescimento do clock, como por exemplo a ecincia (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 tecnolgicos 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) apresentam 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 diminui. 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 fazem 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 diculta o uxo do elemento resfriador (ar, gua, etc.), o que, por sua vez, introduz severas diculdades no processo de dissipao trmica. Alm disto, preciso considerar o fato que em freqncias elevadas cam potencializados os fenmenos de capacitncias e indutncias parasitas, os quais dicultam sobremaneira os nveis de integrao dos semicondutores. Estes dois aspectos independentes se interrelacionam no equilbrio entre desempenho e possibilidade de operao estvel e convel. 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 processadores esbarra no de fato que o uxo 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 denio de uma mquina paralela. Cada estratgia de interconexo (vide item 6.6.2) tem implicaes diretas em aspectos operacionais, tais como: emprego genrico (possibilidade de uso com desempenho desta mquina paralela a um nmero maior de naturezas de problemas), 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 independentes 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 percepo 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 praticamente 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 processadores se mantenha, a computao paralela possibilita para muitas aplicaes uma relao custo/benefcio melhor do que a conseguida ao utilizar equipamentos 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 consideravelmente; deste modo, agrupar em um equipamento paralelo, processadores 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 processadores 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 trabalho em rede de alta velocidade (100 Mbps no mnimo) como alternativa de equiVERSAO

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 componentes 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 tecnolgico, 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 computacionais destacam-se:

inteligncia articial, incluindo redes neurais, robtica e reconhecimento de padres; anlise de elementos nitos, onde aparecem diversos tipos de equaes diferenciais aplicadas a mecnica esttica, eletromagnetismo, e dinmica dos uidos; 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 ssmico; algoritmos bsicos em cincia da computao: classicao, busca e processamento de rvores e grafos; grandes bancos de dados com resposta em tempo real (OLTP On Line Transaction 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 armao que somente um pequeno conjunto de aplicaes poderia ser executado ecientemente em um hardware paralelo. A lista de aplicaes acima indica exatamente o contrrio; a inecincia do processamento paralelo tem muito mais relao com as dimenses do problema" do que com as particularidades de um domnio especco do conhecimento humano. Nos ltimos dez anos os computadores paralelos tem sido programados com ecincia tanto para aplicaes 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 industriais, automaes bancrias, etc.) exigem um regime de operao sem interrupes. A existncia de redundncia de hardware, inerente s arquiteturas paralelas, oferece um suporte natural s tcnicas de tolerncia a falhas. Alguns processadores 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 crescimento 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 gura 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 gura claramente os saltos dados, pelo excesso de capacidade de processamento. O arco cinza escuro na gura 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 arquitetura possa ser expandida gradualmente atravs da adio de mdulos. Esta possibilidade permite uma melhor adequao da curva investimentos & produtividade, 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 nmero tpico para as diferentes marcas seria 1500 aplicaes) que tem potencializado 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 restringir 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 paralelismo. Este aspecto acaba sendo signicativo no momento de decidir pela no adoo de um equipamento paralelo. Tentando traar um perl, 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 deciso de investir no mercado de processamento paralelo ou em outras frentes (por exemplo, melhoramentos em produtos j amplamente utilizados) inuenciada 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 prpria 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 hardware paralelo utilizado. Em funo deste hardware, podero ser necessrias modicaes no layout de dados, no uxo de controle, e at mesmo nos algoritmos bsicos utilizados. O ganho de desempenho, principal razo de ser da adoo do hardware paralelo, poder ser prejudicado com a no observncia criteriosa destas modicaes 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 mquina 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 inuenciados 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 utuante pode apenas se aproximar 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 verso 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, representaes abstratas da computao paralela, lgicas para avaliao da mesma, ou at mesmo algoritmos paralelos que sejam comprovadamente ecientes 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 denida como a estrutura e a organizao 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 gura 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 Classicao de Flynn para Arquiteturas de Computadores


A incluso da proposta feita por Flynn (taxonomia de Flynn) em 1966 , em primeiro lugar, um compromisso com a classicao mais difundida para arquiteturas 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 decodica seqencialmente as instrues, que operam sobre um nico conjunto de dados. Seqncia de Instrues, Mltiplas Seqncias de Dados (SIMD-Single Instruction stream over a Multiple Data stream): corresponde aos processadores matriciais. Nestas arquiteturas, diversos elementos processadores so ativados por somente uma unidade de controle. Esta unidade est submetida a um nico programa, cujas instrues repassam aos elementos processadores. Os processadores executam, concorrentemente, uma mesma instruo sobre os dados que tm na sua memria local. Mltiplas Seqncias de Instrues, uma Seqncia de Dados (MISDMultiple Instruction stream over a Single Data stream): no existem computadores 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 controle e sua memria local (MIMD). Assim, cada n pode executar, de forma assnVERSAO

1.0

PGINA 80

G UIA DE C LUSTER

6.1.1 - A C LASSIFICAO DE F LYNN PARA A RQUITETURAS DE C OMPUTADORES

Figura 6.2: Arquitetura genrica de multiprocessador de memria

crona, um processo independente sobre seus prprios dados (vide gura 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 interconexo (topologia, latncia, conteno, etc.) neste tipo de arquitetura constituem um dos aspectos responsveis pela falta de padro no mercado de arquiteturas paralelas. A congurao 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 compilao disponvel para programao seqencial, agregando mesma os recursos de uma biblioteca para troca de mensagens entre os ns processadores. So propostas usuais que, utilizando desta premissa, exploram conhecidas linguagens seqenciais como C ou FORTRAN para programao paralela. Possibilidade de emular outras arquiteturas: resguardadas as restries inerentes ao desempenho, possvel arquitetura de memria distribuda, emular outros 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

G UIA DE C LUSTER

6.1.1 - A C LASSIFICAO DE F LYNN PARA A RQUITETURAS DE C OMPUTADORES

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 exvel, o particionamento e a alocao de subgrupos de processadores tarefas/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 diminudo. Assim, o processo de planejamento, codicao 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 possibilidade 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 estado conhecido comum, para um grupo de processadores. Para minimizar o possvel 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 ineciente da memria: trs aspectos concorrem para a sobre-ocupao da memria em arquiteturas de memria distribuda. O primeiro decorre da necessidade 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 memria 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 desempenho, de se fazer a cpia local tambm das estruturas de dados globais que o algoritmo possa necessitar.

VERSAO

1.0

PGINA 82

G UIA DE C LUSTER

6.1.1 - A C LASSIFICAO DE F LYNN PARA A RQUITETURAS DE C OMPUTADORES

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 gura 6.3). So tambm denominados de multiprocessadores simtricos ([128], [280]). Uma das razes do sucesso comercial deste tipo de arquitetura MIMD, decorrente da sua exibilidade de uso. Cada processador da arquitetura 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 seqencial j existente, praticamente sem nenhuma modicao. Deste modo, o paralelismo 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 transforme 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 compartilhada o uso de uma memria cache entre o processador e a memria comum. A busca de um sistema eciente para manuteno da coerncia de memria neste tipo de arquitetura um tema complexo e originou diversos trabalhos de pesquisa. A utilizao destes sistemas propica vrios aspectos positivos como:

Abstrao da localidade do processador: neste tipo de arquitetura o programaVERSAO

1.0

PGINA 83

G UIA DE C LUSTER

6.1.1 - A C LASSIFICAO DE F LYNN PARA A RQUITETURAS DE C OMPUTADORES

dor pode abstrair a localidade do processador. Deste modo, a troca de mensagens sincronizada por um mecanismo de escrita em variveis comuns. Como a memria sicamente 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 execuo efetivamente paralela. Facilidade de uso mltiplo: os processadores podem ser alocados individualmente ou em grupos, para diferentes programas/usurios. Maior compartilhamento dos recursos: a memria comum facilita o compartilhamento de estruturas de dados globais. Por sua vez, os recursos de entrada/sada e de memria virtual podem ser aproveitados por todos os ns processadores. 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 arquiteturas 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 unidade de controle. Esta unidade busca e decodica 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

G UIA DE C LUSTER

6.1.1 - A C LASSIFICAO DE F LYNN PARA A RQUITETURAS DE C OMPUTADORES

esto intencionalmente inibidos) executam sincronamente uma mesma instruo sobre sua parte dos dados. O paralelismo se d, portanto, pela manipulao simultnea 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 m 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, ca localizado em uma estao de trabalho que atua como intermediria (front-end) para a arquitetura. Esta estao acumula as funes de gerenciamento de contas 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 aglutinao 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 cam 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 eciente 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 tamanho da matriz de processadores cresce, podem surgir diculdades de garantir, atravs de uma rede de interconexo de grandes dimenses, a operao totalmente sncrona dos processadores (este aspecto se potencializa com o crescimento constante do clock dos processadores). A Inecincia ante desvios condicionais; os desvios condicionais dependentes de dados, precisam ser processados independentemente, um aps o outro. Esta situao vista como um dos principais pontos de perda de desempenho desta arquitetura. E a Diculdade de compartilhamento; uma vez que existe somente uma unidade de controle, a arquitetura somente pode ser utilizada por um programa/usurio de cada vez. Alguns fornecedores facultam a existncia de mais de um controlador central (com o decorrente 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 sistema local de interconexo. Essa arquitetura caracterizada pelo compartilhamento global de memria pelos diversos processadores do ambiente e esse compartilhamento global de memria 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 congurao 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 arquitetura caracterizada por ter at milhares de processadores. No h um compartilhamento 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 congurao de multicomputadores a criao de um cluster com PCs convencionais usando uma rede local ethernet. Diferente da congurao de multiprocessadores em que necessrio utilizao de um comutador especial, esse tipo de cluster utiliza peas encontradas em qualquer estabelecimento de informtica.

6.1.4 Multiprocessadores Simtricos (Symmetric Multiprocessors - 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 processadores 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, reexo da reduo de custos destes equipamentos. Um problema desta arquitetura sua escalabilidade, pois com o aumento do nmero 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 normalmente sistemas de interconexo na forma de barramento. Este tipo de interconexo 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. Tambm 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 conguraes 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 memria 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 rodarem nessa plataforma.

6.1.6 Processadores Massivamente Paralelos - MPP


Mquinas com congurao massivamente paralelas (Massive Parallel Processors MPP), so arquiteturas fracamente acopladas. Computadores que seguem este paradigma so usualmente classicados como multicomputadores, e normalmente 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 compartilhada. Os maiores computadores classicados na lista TOP500 [364] usam este paradigma. Uma parte importante na congurao 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 uxo entre ns.

6.1.7 Sistemas Distribudos


Os sistemas distribudos, sob o aspecto da arquitetura de mquinas, para a execuo de aplicativos, podem ser vistos como conguraes com grande poder de escalabilidade, pela agregao dos computadores existentes nas redes convencionais 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 conguraes de SMPs, clusters, MPPs e grids computacionais. ([136]) Vrios aspectos na utilizao de ambientes distribudos tm de ser cuidados, aspectos como segurana, conabilidade, latncia da rede de comunicaes, compatibilidades 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 conguraes de clusters em termos de arquitetura computacional, podem ser entendidas como uma agregao de computadores de forma dedicada para a execuo de aplicaes especcas. 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 geogracamente dispersos, com objetivos claros de especicao de qualidade de servios. Atualmente, a Internet com uma congurao distribuda de recursos conhecida como o ambiente que melhor pode demonstrar esse tipo de arquitetura. Em outras palavras, diferentes tipos de aplicativos com diferentes tipos de requerimentos de qualidade (exemplos so a largura de banda, latncia de comunicaes e jitter1 ) so tratados de maneira igual. Em adio, os servios WEB"que oferecem servios para a execuo de tarefas de usurios nais so crescentes. Desta forma, o objetivo destas conguraes voltar toda a potencialidade de recursos e servios disponveis para o processamento de tarefas dos usurios pertencentes congurao 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 conabilidade (reliability), disponibilidade (availability), segurana (safety), mantenabilidade (maintainability), comprometimento do desempenho (performability), e testabilidade (tes1 Jitter uma variao estatstica do latncia na entrega de dados em uma rede, ou seja, pode ser denida 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 quanticar a dependabilidade de um sistema. ([304]) Assim pode-se dizer que a dependabilidade uma propriedade dos sistemas computacionais que dene a capacidade dos mesmos de prestar um servio no qual se pode justicadamente conar (DANTAS [136]). Conabilidade a medida mais usada em sistemas em que mesmo curtos perodos de operao incorreta so inaceitveis. Conabilidade uma medida probabilstica 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. Performability est relacionada queda de desempenho provocada por falhas, onde o sistema continua a operar, mas degradado em desempenho. Mantenabilidade signica a facilidade de realizar a manuteno do sistema, ou seja, a probabilidade que um sistema com defeitos seja restaurado a um estado operacional dentro de um perodo determinado. Restaurao envolve a localizao do problema, o reparo e a colocao em operao. Finalmente, testabilidade a capacidade de testar atributos internos ao sistema ou facilidade de realizar certos testes. Quanto maior a testabilidade, melhor a mantenabilidade, por conseqncia, menor 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 melhores vistos.

6.2.1 Ameaas
Um defeito denido como um desvio da especicao, 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. Dene-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 universo 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 informao) 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. Informaes mais detalhadas sobre este tpico podem ser obtidas em DANTAS [136].

6.2.2 Meios
Os meios da classicao de dependabilidade nos ajudam a trabalhar na preveno, 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 conabilidade 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 m 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 denido como a capacidade de um sistema apresentar um comportamento bem denido 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 no garantida Mascaramento Segurana no garantida Operacionalidade Garantida Segurana garantida Defeito seguro (fail safe) 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 modicado pela ocorrncia 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 modicam 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 principal. 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 remoo 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 desenvolvimento realizada atravs das etapas de vericao, diagnstico e correo. A vericao 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 dependabilidade. Esta opo considera uma avaliao do comportamento do sistema com relao ocorrncia e ativao de falhas. Esta abordagem pr-ativa pode subsidiar as modicaes para melhorias, tanto estruturais como para melhor ecincia/eccia dos sistemas.

6.2.3 Atributos
Os atributos de dependabilidade tm naturezas no determinsticas das circunstncias dos atributos que so: Disponibilidade, Conana, Segurana, Condenciabilidade, Integridade, Reparabilidade. Esses atributos usam medidas probabilsticas 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, denido como a probabilidade de um sistema apresentar um servio correto, num determinado instante de tempo t. Na anlise de disponibilidade estamos interessados no comportamento de um sistema em determinados perodos de tempo, ou seja, estamos preocupados em observar a alternncia de perodos de funcionamento correto 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. Conabilidade: a mtrica que avalia, o quanto um sistema pode apresentar um servio correto continuamente durante um intervalo de tempo t, ou seja, a probabilidade do sistema no apresentar defeito durante o intervalo de tempo considerado. Segurana: considerada sob dois aspectos: contra catstrofes e convencional. Contra catstrofes a probabilidade do sistema apresentar defeito que acarrete
VERSAO

1.0

PGINA 94

G UIA DE C LUSTER

6.3 - E SCALONAMENTO

conseqncias catastrcas para seus usurios em um intervalo de tempo. E segurana convencional a probabilidade obtida atravs da combinao dos atributos: disponibilidade, condencialidade e integridade, ou seja, a probabilidade de que no ocorra acesso ou manipulao indevida no estado do sistema no intervalo de tempo. Condenciabilidade: 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 alocao 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 minimizao 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 distribuio de trabalho computacional para as unidades de processamento integrantes do sistema, de modo a maximizar o desempenho global do processamento realizado, isto , promover o balanceamento de carga entre as unidades de processamento envolvidas.
VERSAO

1.0

PGINA 95

G UIA DE C LUSTER

6.3 - E SCALONAMENTO

Em sistemas homogneos, o problema de balanceamento de carga pode ser reduzido a uma diviso de um determinado trabalho computacional em N pores iguais e que possam ser distribudas e executadas por N unidades de processamento do sistema, supostamente idnticas. Neste caso, o problema est fortemente 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 consideravelmente mais complexo e, nestas circunstncias, o escalonador de tarefas ganha especial importncia. Para que o conjunto heterogneo de unidades de processamento possa ser utilizado de maneira eciente, questes como predio e monitoramento de desempenho, passam a integrar o problema de balanceamento de carga. Isso signica que um bom compromisso, entre o tempo de processamento despendido na busca por uma soluo e a qualidade da soluo encontrada, deva ser satisfeito, e no contexto deste compromisso que as principais linhas de desenvolvimento 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 denida; 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 funcionamento 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 circunstncias, 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 signicativos decrscimos. Apesar desta aparente limitao, o escalonamento esttico largamente utilizado
VERSAO

1.0

PGINA 96

G UIA DE C LUSTER

6.3 - E SCALONAMENTO

em sistemas paralelos reais, uma vez que sua simplicidade de implementao lhe confere grande robustez e facilidade de manuteno. Nestes sistemas a ocorrncia de eventos que afetem signicativamente 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 estticos 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 escalonadores dinmicos, o que justica 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, benecia-se da habilidade 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, estimativas imprecisas ainda podem signicar um escalonamento ineciente. 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 reescalonamento das tarefas restantes a serem executadas. Uma vantagem adicional do fato de seu processamento ser realizado concorrentemente a execuo da aplicao escalonada e que isso pode signicar economia de tempo global com relao ao caso esttico. Entretanto, os escalonadores dinmicos possuem seus inconvenientes. Em contrapartida aos escalonadores estticos, a implementao dos escalonadores dinmicos 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 maneiVERSAO

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 diferentes topologias de interconexo, cada qual adaptado s caractersticas do ambiente 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, modicada, armazenada pelo maior tempo possvel levou fabricantes de hardware e desenvolvedores de software a pensarem em maneiras de como contornar esses problemas de paradas de sistemas, sejam elas causadas por falhas internas (causadas por mal funcionamento de hardware, erros introduzidos por softwares ou outras razes 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 gerenciando falhas (mais detalhes em 6.2.2) bem como minimizando tempo de desligamento planejado para manuteno. Este conceito no se resume a um software especco, mas a um conjunto de mecanismos 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 avaliao de solues HA: nveis de disponibilidade segundo tempos de indisponibilidade (downtime). Excludos desta tabela, os tempos de downtime estimados (geralmente para manuteno ou recongurao 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 (%) 95 96 97 98 99 99,9 99,99 99,999

Downtime/ano 18 dias 6:00:00 14 dias 14:24:00 10 dias 22:48:00 7 dias 7:12:00 3 dias 15:36:00 0 dias 8:45:35.99 0 dias 0:52:33.60 0 dias 0:05:15.36

Downtime/ms 1 dia 12:00:00 1 dia 4:48:00 0 dias 21:36:00 0 dias 14:24:00 0 dias 7:12:00 0 dias 0:43:11.99 0 dias 0:04:19.20 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 indisponvel 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 softwares 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 sistema comea a se tornar excessiva, preciso buscar uma soluo para o aumento de capacidade do sistema, que pode ser basicamente: i) aquisio de uma mquina de maior capacidade computacional, ii) melhoria de performance do sistema 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 clustering, 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 ecincia do sistema da rede de comunicao entre os ns de extrema importncia e criticidade. Se a rede falha ou tem baixo desempenho, o cluster inteiro sentir esse problema e, por conseqncia, o desempenho do sistema como um todo ser atingido. Assim comum se projetar redes para cluster pensando no apenas no desempenho e latncia desta, mas tambm na alta-disponibilidade da rede. importante considerar que uma rede um elemento bastante seguro a nvel fsico: dicilmente uma vez instalada, a rede sicamente ir falhar. Outro tpico importante da rede a sua ecincia: uma rede congestionada destri 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 ecincia 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 Paralelas


No importando o tipo da arquitetura, todo computador paralelo necessita de uma rede de interconexo para criar canais de comunicao entre os seus diversos recursos de processamento, armazenamento e entrada/sada. Considerando a diversidade das alternativas tecnolgicas, esta seo vai explorar aspectos centrais pertinentes ao tema, a partir dos quais, podem ser entendidas as vrias alternativas 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 gura 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 mltiplas mensagens concorrentes, o que em determinadas situaes pode ser oportuno para explorao do paralelismo. Como exemplo, temos o emprego 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 vantagem deste caso a maior exibilidade 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 arquiteturas 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 processador e a chave de interconexo o prejuzo do nvel de integrao (mais circuitos integrados, mais conexes, etc.).

Caractersticas que Denem o Desempenho de uma Rede de Interconexo

Alm da topologia da rede de interconexo, as outras caractersticas que se destacam na denio do seu desempenho so:

largura de banda do canal: nmero de bytes por segundo que pode uir entre dois ns com conexo direta. Via de regra, a largura de banda depenVERSAO

1.0

PGINA 101

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 comutao. 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 latncias 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. Muitas 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 mensagens 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
VERSAO

1.0

PGINA 102

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 denir 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 trocadas 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 (enviadas ou recebidas) simultaneamente por cada um dos processadores.

Topologia em Barramento

Nesta topologia, todos os processadores esto conectados em um nico barramento compartilhado. Quando um processador necessita comunicar-se com outro, ele aguarda que o barramento esteja livre e propaga no mesmo a mensagem; o destinatrio, por sua vez, identica que a mensagem para si e a recebe (vide gura 6.6). No caso de duas transmisses simultneas, o software detector de colises interrompe 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 signica que esta topologia no permite mais do que um par de processadores em comunicao simultaneamente.
VERSAO

1.0

PGINA 103

G UIA DE C LUSTER

6.6.3 - T OPOLOGIAS DA R EDE DE I NTERCONEXO

Figura 6.6: Topologia em barramento

Do ponto de vista do desempenho, esta topologia somente vivel para um pequeno nmero de processadores e/ou classes de problemas cujos algoritmos implementem 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 congurao denominada malha toroidal (b), a qual reduz o dimetro da malha por um fator de 2 (vide gura 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 xo 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 cientcos, onde se destaca a manipulao de matrizes. Uma arquitetura que utiliza esta topologia o Intel Paragon.
VERSAO

1.0

PGINA 104

G UIA DE C LUSTER

6.6.3 - T OPOLOGIAS DA R EDE DE I NTERCONEXO

Topologia em Hipercubo

Toda rede de interconexo hipercbica est alicerada sobre uma estrutura multidimensional baseada em endereos binrios. Os tamanhos do hipercubo so denidos 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 identicados 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 gura 6.8).

Figura 6.8: Topologia em hipercubo

A topologia hipercbica confere boas propriedades rede de interconexo; a largura da bisseo N/2, e o dimetro log2 N . Apesar de apresentar bom desempenho para muitos padres de comunicao, sua ecincia se mostra bastante dependente do algoritmo de roteamento a ser empregado. Um aspecto inconveniente do hipercubo sua escalabilidade, o nmero de processadores 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.
VERSAO

1.0

PGINA 105

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 rvore 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 variante denominada rvore larga. Em uma rvore larga (vide gura 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 modicada 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
VERSAO

1.0

PGINA 106

G UIA DE C LUSTER

6.6.4 - D ISPOSITIVOS DE INTERCONEXO

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 necessidade criada pelo aumento da largura de banda nas "pontas"das redes (ex.: servidores 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 tecnologia Ethernet e o seu baixo custo. Trata-se de uma tecnologia padro, protegendo o investimento feito em recursos humanos e em equipamentos. No h nenhuma nova camada de protocolo para ser estudada, conseqentemente, h uma pequena curva de tempo de aprendizagem em relao atualizao dos prossionais. 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 aplicaes, como a videoconferncia com grande nmero de participantes, ou mesmo uma transmisso de vdeo em tempo-real de um ponto para muitos outros.
VERSAO

1.0

PGINA 107

G UIA DE C LUSTER

6.6.4 - D ISPOSITIVOS DE INTERCONEXO

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 trco 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 uxo 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 informaes. O uxo do remetente pode ser bloqueado, temporariamente, pelo receptor a qualquer hora, durante ou entre pacotes, usando controle de uxo. Num ambiente de comunicao convel pode-se empregar roteamento cutthrough", 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 ca enleirado num circuito de roteamento ou n, que supostamente tem memria suciente para bufferizar o pacote. J no roteamento cut-through"os circuitos de roteamento podem bloquear com controle de uxo se o canal de sada no estiver disponvel. Desta forma o circuito de roteamento cut-through"no requer bufferizao, pois cada link pode prover seu prprio controle de uxo. Para prover o controle de uxo, as redes MPP reconhecem cada unidade de uxo de controle, tipicamente um byte.

InniBand

InniBand uma arquitetura que dene 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, desenvolvida pela Compaq, IBM e Hewlett-Packard com a Next Generation I/O (ngio), desenvolvido por Intel, Microsoft, Dell, Hitachi, Siemens e Sun Microsystems.
VERSAO

1.0

PGINA 108

G UIA DE C LUSTER

6.6.4 - D ISPOSITIVOS DE INTERCONEXO

Em agosto de 1999, os sete lderes da indstria, Compaq, Dell, Hewlett-Packard, IBM, Intel, Microsoft e Sun Microsystems formaram a IBTA (InniBand Trade Association). A primeira especicao da arquitetura InniBand foi feita em junho de 2001. A arquitetura InniBand surgiu devido necessidade de se melhorar o desempenho dos dispositivos de E/S e das comunicaes, que surgiu juntamente com o aumento da capacidade de processamento dos processadores. InniBand uma arquitetura ponto-a-ponto que se destina a fornecer aos centros de dados uma conectividade para entradas/sadas melhoradas e adaptadas a qualquer tipo de trfego. Uma conexo InniBand 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, comutadores, 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 subsistemas de E/S. A tecnologia InniBand 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 InniBand so a baixa latncia e alta largura de banda. A baixa latncia benecia principalmente as aplicaes sensveis latncia, com comunicao entre processos (IPC) e sistemas gerenciadores de bancos de dados (DMBS). A alta largura de banda benecia principalmente as aplicaes que necessitam grande largura de banda, como armazenamento, web, computao de alto desempenho, e outras aplicaes especializadas, como edio de vdeo. Devido a suas caractersticas, InniBand uma tecnologia adequada para aplicaes de HPC (High Performance Computing). Enquanto InniBand prov muitas caractersticas avanadas que servem para um grande leque de aplicaes, contudo esta tecnologia ainda um padro em evoluo e deve sofrer muitas melhorias. Algumas das melhorias planejadas para InniBand incluem especicaes
VERSAO

1.0

PGINA 109

G UIA DE C LUSTER

6.6.4 - D ISPOSITIVOS DE INTERCONEXO

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 compatibilidade com tecnologias de rede como HIPPI, Ethernet, e outros padres de rede. GSN tem uma alta capacidade de banda (800MB por segundo) e baixa latncia. Caractersticas:

Capacidade de Banda: acima de 800MB por segundo em full-duplex. Velocidade 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 outro 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.
VERSAO

1.0

PGINA 110

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 componentes de um cluster. A abordagem cria um sistema de compartilhamento de memria 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 eciente 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 xo (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 Identier) que utilizado 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 especicamente, 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 xo, e dispensando protocolos de correo de erros.
VERSAO

1.0

PGINA 111

G UIA DE C LUSTER

6.7.3 - FDDI

6.7.3 FDDI
O padro FDDI (Fiber Distributed Data Interface) foi estabelecido pelo ANSI (American 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 campus. As redes FDDI adotam uma tecnologia de transmisso idntica s das redes Token Ring, mas utilizando, comumente, cabos de bra 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 bra ptica duplo, com congurao 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 especca. O modelo tem como propsito facilitar o processo de padronizao e obter interconectividade 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 comunicao entre mquinas heterogneas, denominado OSI (Open Systems Interconnection). Esse modelo serve de base para qualquer tipo de rede, seja de curta, mdia ou longa distncia.
VERSAO

1.0

PGINA 112

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 encaminhamento dos dados. Os dados numa rede IP, so enviados em blocos referidos como pacotes ou datagramas (os termos so basicamente sinnimos no IP, sendo usados para os dados em diferentes locais nas camadas IP). Em particular, no IP nenhuma denio necessria antes do host tentar enviar pacotes para um host com o qual no comunicou previamente. O IP oferece um servio de datagramas no convel (tambm chamado de melhor 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 aplicao precisa de conabilidade, 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 robustez deste protocolo tornou-o adequado para redes globais, j que este verica 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.
VERSAO

1.0

PGINA 113

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 signica protocolo de datagramas de utilizador (ou usurio). O UDP faz a entrega de mensagens independentes, designadas por datagramas, entre aplicaes ou processos, em sistemas host. A entrega no convel", porque os datagramas podem ser entregues fora de ordem ou at perdidos. A integridade dos dados pode ser gerida 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. Dene como deve ser feita a fragmentao do uxo de dadosudio, 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 garantia que os pacotes sero entregues num determinado intervalo. Os protocolos RTP/RTCP so denidos 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 especicado pela IEFT2 (RFC 3768) que permite dois ou mais roteadores atuarem como um roteador virtual. De acordo com essa especicao, 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


1.0 PGINA 114

VERSAO

G UIA DE C LUSTER

6.7.9 - Virtual Router Redundancy Protocol

As trocas de mensagem, para vericao de estado entre os servidores, acontecem atravs de IP multicast. Uma falha no recebimento dessas mensagens em um intervalo especico 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) Identicao 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 prioridade).

Figura 6.10: Esquema de funcionamento de um sistema VRRP

VERSAO

1.0

PGINA 115

G UIA DE C LUSTER

6.7.9 - Virtual Router Redundancy Protocol

Na gura 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 nalidades principais:

. Forar a eleio de outro master caso haja algum com maior prioridade. . Noticar instncias VRRP de backup que h um master ativo, caso no exista comunicao em intervalo denido, haver uma nova escolha de master.

VERSAO

1.0

PGINA 116

Captulo 7 Cluster de Armazenamento

7.1 Introduo
O aumento da capacidade de processamento e a maior utilizao de sistemas informatizados 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 armazenamento de dados, de uma maneira geral podem ser classicadas 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 Devices, Sistemas de arquivos distribudos, Sistemas de Arquivos Paralelos, Dispositivos Raid, Controladoras de Discos, entre outras.
1

1P etaByte = 1.073.741.824M egaByte


1.0 PGINA 117

VERSAO

G UIA DE C LUSTER

7.2 - Block Devices

Tecnologias de Armazenamento Ofine - Encontram-se neste grupo as tecnologias de armazenamento normalmente utilizadas para armazenar dados de backup ou dados que no precisam ser acessados online. Alguns exemplos de tecnologias que encontram-se neste grupo so: Fitas, CD, DVD, dispositivos de tas, bibliotecas de tas.

Em sistemas crticos normalmente so utilizados dispositivos de armazenamento proprietrios denominados "Storage Devices"e/ou "Bibliotecas de Fita"que possuem capacidade de armazenar Terabytes de informaes, com funcionalidades que permitem consolidar e manter a integridade dos dados em um ambiente centralizado. 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 denio 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]
VERSAO

1.0

PGINA 118

G UIA DE C LUSTER

7.2.1 - A RRANJO R EDUNDANTE DE D ISCOS - RAID

A diferena mais signicante entre dispositivos de blocos e dispositivos de carter, 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 pedido 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 completo 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 explorao de dispositivos de armazenamento. Existem vrias implementaes de Dispositivos de Blocos com a inteno de serem 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 replicar 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 combinar mltiplos dispositivos de baixo custo usando uma tecnologia mais antiga em uma disposio que oferecesse uma grande capacidade de armazenamento, conabilidade, 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 geralmente, mas no necessariamente, implementado com discos rgidos de tamanhos idnticos. Com as diminuies dos preos de discos rgidos e com a disponibilidade em
VERSAO

1.0

PGINA 119

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 Workstations para aplicaes que necessitam de utilizao intensiva de disco, seja de leitura/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 ca 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/SBus/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 computador; 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 fornecer 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 considervel 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, fabricantes 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 congurao e geVERSAO

1.0

PGINA 120

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 congurao 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 exvel que uma soluo por hardware. O problema que ele em geral requer mais ciclos e capacidade da CPU para funcionar bem, quando comparado a um sistema de hardware, mas tambm oferece uma importante e distinta caracterstica: opera sobre qualquer 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 unica unidades de disco inteiras em um arranjo. Comparando as duas solues, o RAID via hardware transparente para o sistema operacional, e isto tende a simplicar o gerenciamento. J o via software, tem mais opes e escolhas de conguraes, fazendo sua manipulao mais complexa.

7.2.3

Distributed Replicated Block Device - DRBD

Projeto:DRBD Stio Ocial: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 dispoVERSAO

1.0

PGINA 121

G UIA DE C LUSTER

7.2.3 - Distributed Replicated Block Device - DRBD

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 gura 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 transferncias so efetuadas pelo protocolo TCP/IP, o que permite sua implementao at mesmo em mquinas geogracamente 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 diretamente. 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 primrio 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 vericao da consistncia do sistema de arquivos; em Linux, signica executar o fsck. Para evitar a execuo da vericao 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 conguraes, 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
VERSAO

1.0

PGINA 122

G UIA DE C LUSTER

7.2.3 - Distributed Replicated Block Device - DRBD

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 reduzir estas diculdades 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:


VERSAO

1.0

PGINA 123

G UIA DE C LUSTER

7.2.3 - Distributed Replicated Block Device - DRBD

Figura 7.2: Fluxo de intercomunicao entre as camadas dos dispositivos Linux - repare que o DRBD no tem como noticar o mdulo do sistema de arquivos - mas o oposto ocorre.

Se as parties no forem do mesmo tamanho, o dispositivo DRBD ir automaticamente assumir-se como sendo do tamanho mnimo entre as parties envolvidas - o que permite alguma exibilidade 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 noticar alteraes na camada que gere o sistema de arquivos embutido.

Situao do projeto

A maioria dos clusters HA (HP,Compaq,...) atualmente utilizam dispositivos de armazenamento compartilhados; estes dispositivos, altamente dispendiosos, permitem 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 neVERSAO

1.0

PGINA 124

G UIA DE C LUSTER

7.2.4 - Global Network Block Device - GNBD

cessita de nenhum hardware especco. 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 suciente 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 suciente 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 compartilhado capaz de gerenciar o lock de acesso de maneira global ao sistema de arquivos, garantindo a integridade dos dados. No se deve ser utilizado sistemas 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 Ocial: 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,
VERSAO

1.0

PGINA 125

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, Pendrive, 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 localmente 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 desenvolvida 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 conguraes com um grande nmero de clientes, 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 recomendado 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 gura 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.

Storage Area Network


1.0 PGINA 126

VERSAO

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, ocialmente raticado 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 especicaes 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
VERSAO

1.0

PGINA 127

G UIA DE C LUSTER

7.2.5 - I NTERNET SCSI - I SCSI

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 Ofoad Engine (TOE3 ) ajudam a reduzir este overhead. De fato, com a performance disponvel nos servidores modernos, uma interface de rede padro com um driver eciente pode superar a performance de uma placa TOE porque menos interrupes e menos transferncias 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 implementarem 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 ta 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 aparecem 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 controle de requisies de acessos simultneos de vrios Hosts. Permitir que mltiplos 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
1.0 PGINA 128

VERSAO

G UIA DE C LUSTER

7.2.5 - I NTERNET SCSI - I SCSI

iSCSI Conceitos e Viso Funcional

O protocolo iSCSI responsvel pela execuo de comandos SCSI entre dois dispositivos em uma rede TCP/IP. Comandos SCSI so executados atravs de chamadas 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 comunicaes 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 denido 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 superiores http://www.open-iscsi.org/. UNH-iSCSI - Initiator e target implementado pela University of New Hampshire.
VERSAO

1.0

PGINA 129

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 sistemas de arquivos distribudos e paralelos, assim como algumas de suas caractersticas, qualidades e solues ([192], [351]) que os pesquisadores e desenvolvedores 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 identica unicamente em tal sistema. Um caminho representa um n de uma estrutura de diretrios, que pode ser representada como uma rvore (veja g. 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 nal, procurar pelo nome de tal arquivo. A forma como esse nome e esse caminho so denidos depende muito do sistema operacional. Por exemplo, no Unix um
VERSAO

1.0

PGINA 130

G UIA DE C LUSTER

7.3.1 - C ONCEITOS B SICOS

Figura 7.4: Exemplo de uma rvore de diretrios

caminho denido 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 denio 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 dados 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
VERSAO

1.0

PGINA 131

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 armazenamento 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 nal 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;
VERSAO

1.0

PGINA 132

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 losoa usada no sistema de arquivos virtual (VFS) do Solaris e do Linux; Replicao: Os arquivos do SAD podem ter cpias armazenadas em locais 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 arquivo ao mesmo tempo, mas isso no deve ser perceptvel para esses usurios; 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 complexidade por trs dos engenhosos algoritmos e idias desenvolvidas pelos pesquisadores 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 armazenada no nome dele, como por exemplo jaca:/tmp/teste, ento esse servio de nomes no prov transparncia de localizao. Para prover essa transparncia, o nome ou caminho de um arquivo no deve ter indcios de sua localizao fsica.
VERSAO

1.0

PGINA 133

G UIA DE C LUSTER

7.3.2 - S ERVIOS O FERECIDOS PELOS SAD S

Caso esse arquivo mude de lugar, ou tenha vrias cpias, o seu nome ou caminho 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 nomes de arquivos compreensveis por computadores, que normalmente so nmeros, 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 localizao. Por exemplo, nmeros de telefone possuem cdigo do pas, da localidade, etc. Se transparncia por nome e por localizao estiverem sendo utilizadas simultaneamente, 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, enquanto 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, dependendo 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.
VERSAO

1.0

PGINA 134

G UIA DE C LUSTER

7.3.2 - S ERVIOS O FERECIDOS PELOS SAD S

Tambm responsabilidade desse servio manter a integridade das operaes realizadas nos arquivos. Por exemplo, quando uma aplicao altera algum arquivo, todas as demais aplicaes que estiverem acessando-o devem perceber essa alterao 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 funciona se o cliente tiver espao suciente para armazenar o arquivo. A velocidade da rede s inuenciar durante as transmisses do arquivo de um local a outro e a implementao s ser considerada muito eciente caso o arquivo seja totalmente 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 servidor que 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 identicar e remover arquivos que no estejam em diretrio algum, como por exemplo quando um diretrio
VERSAO

1.0

PGINA 135

G UIA DE C LUSTER

7.3.2 - S ERVIOS O FERECIDOS PELOS SAD S

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 signica 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 inuenciam nesse contador. Exemplicando, a gura 7.5 mostra uma estrutura de diretrios distribuda em dois servidores. Se for requisitada a remoo da ligao A E (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 removidos. 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 inuncia no gerenciamento de arquivos, como nas operaes de criao, remoo, mudana de nome, busca, duplicao, entre outras.

VERSAO

1.0

PGINA 136

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 tolerncia 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 energia 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, car fora do ar ou da rede, o sistema de arquivos no pode perder informaes e nem car inacessvel total ou parcialmente. Alm disso, o usurio no precisa saber como isso foi implementado. Ele simplesmente requisita um arquivo e o sistema de arquivos deve entreg-lo, mesmo que algum dos servidores esteja fora do ar. O arquivo no pode car indisponvel e isso deve ser totalmente transparente ao usurio. Isso se chama transparncia a falhas. muito comum sistemas carem indisponveis no por falha do prprio servidor, mas por falha na rede de comunicaes. Caso um cliente deseje acessar um arquivo que est em um servidor inacessvel naquele momento, o sistema operacional do cliente costuma travar o processo que o pediu at que o servidor volte a car 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. Assim, caso algum servidor que 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.
VERSAO

1.0

PGINA 137

G UIA DE C LUSTER

7.3.3 - A LGUMAS C ARACTERSTICAS D ESEJADAS EM SAD S

Escalabilidade

Os sistemas distribudos so, em geral, projetados e congurados pensando-se na congurao 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, dicilmente 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 tenha distribudo sistema de arquivos em muitos servidores, ca difcil descobrir onde um arquivo est armazenado sicamente. Por exemplo, se para abrir um arquivo um cliente tiver que perguntar para cada servidor se ele o responsvel por aquele arquivo, certamente haver um congestionamento na rede. Caso se tente resolver isso colocando um servidor central para resolver todos os caminhos 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 hierarquizao da rede. Esse SAD descrito na sesso 7.3.5.
VERSAO

1.0

PGINA 138

G UIA DE C LUSTER

7.3.3 - A LGUMAS C ARACTERSTICAS D ESEJADAS EM SAD S

Segurana

Compartilhar arquivos entre vrios ambientes e usurios uma das vantagens que os sistemas de arquivos distribudos trazem. Porm, deixar que outras pessoas possam acessar arquivos condenciais um grande problema. Dessa forma, torna-se necessrio adotar mecanismos de segurana, para evitar que pessoas desautorizadas 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, verica se tal usurio tem permisso suciente 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 identicao 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 identicar 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 elementos 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 proteglos. Porm, caso haja outras mquinas no caminho de duas mquinas conveis,
VERSAO

1.0

PGINA 139

G UIA DE C LUSTER

7.3.3 - A LGUMAS C ARACTERSTICAS D ESEJADAS EM SAD S

existe o risco de se ter dados interceptados ou, at mesmo, adulterados. Uma forma de se resolver esse problema criptografar as informaes antes de envilas. 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 criptogrca. A vantagem que o servidor no precisa vericar se a prova da capacidade autntica: se ela no for, o cliente no conseguir decodicar os dados. Meios mais modernos e ecazes para o controle da segurana no acesso e manipulao dos dados armazenados podem ser encontrados em [192].

Tolerncia a Falhas

Durante a transmisso dos dados entre servidores e clientes, falhas podem ocorrer, seja por excesso de trfego de pacotes pela rede, seja por algum dos servidores estar sobrecarregado. Alm disso, podem ocorrer falhas de hardware, especialmente 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 conveis. Dessa forma, um sistema distribudo precisa usar um protocolo de comunicao 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 (realizada atravs de hardware) ou redundncia controlada pelo prprio sistema distribudo, que cuidaria de replicar os dados, j evitaria a perda das informaes armazenadas.
VERSAO

1.0

PGINA 140

G UIA DE C LUSTER

7.3.3 - A LGUMAS C ARACTERSTICAS D ESEJADAS EM SAD S

Seja qual for o problema, o sistema deve evitar que o cliente que aguardando uma resposta por muito tempo, ou que seus dados sejam danicados ou at mesmo perdidos. Isso signica que o servio precisa ter disponibilidade e conabilidade. Porm, essas caractersticas podem ser conitantes se no forem bem aplicadas. Por exemplo, para garantir a conabilidade necessrio implementar redundncia dos dados, porm a complexidade que isso gera pode aumentar demais a carga do servidor, comprometendo a disponibilidade, pois as respostas aos clientes seriam mais lentas. Outro mecanismo que auxilia a conabilidade a transao. Ela evita que o contedo de algum arquivo que 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]. Assim, 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 implementadas 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 m. O comando de incio avisa ao sistema que todas as operaes a partir daquele ponto estaro dentro da transao e o comando de nalizao indica que
VERSAO

1.0

PGINA 141

G UIA DE C LUSTER

7.3.3 - A LGUMAS C ARACTERSTICAS D ESEJADAS EM SAD S

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 rollback ou abort. Caso todas as operaes sejam executadas sem problemas ou erros, ao chegar no m da transao realizado um commit, ou seja, todas as alteraes 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 sistemas 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 sofrer danos, perda de desempenho ou quaisquer outras restries. Isso tudo deve ocorrer sem que o usurio precise saber como o acesso realizado pelos servidores. 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.
VERSAO

1.0

PGINA 142

G UIA DE C LUSTER

7.3.3 - A LGUMAS C ARACTERSTICAS D ESEJADAS EM SAD S

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 armazenado 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 recebendo o depsito. Esta aplicao, ento, ir adicionar ao saldo o valor do depsito 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 processo decidir se espera na la 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 serializao 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.

VERSAO

1.0

PGINA 143

G UIA DE C LUSTER

7.3.3 - A LGUMAS C ARACTERSTICAS D ESEJADAS EM SAD S

Porm esse protocolo pode gerar um travamento (deadlock), onde um processo esperaria a liberao de um arquivo que foi bloqueado por outro processo, que tambm estaria esperando a liberao de um arquivo que foi bloqueado por aquele primeiro processo, por exemplo. Para evitar travamentos em sistemas distribudos, 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 ecincia e a conana do servio de arquivos generosamente aumentada. Ecincia em termos de tempo de resposta, carga do servidor e trfego de rede. Conana caso um determinado servidor caia ou que 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.
VERSAO

1.0

PGINA 144

G UIA DE C LUSTER

7.3.3 - A LGUMAS C ARACTERSTICAS D ESEJADAS EM SAD S

A centralizada consiste de um nico servidor que cuida dos pedidos dos clientes atravs de handles. Com esses handles, os clientes acessam diretamente os arquivos 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 dizendo 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 signica que quando um cliente pedir permisso para alterar 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 construda 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 compartilhados em uma rvore de diretrios. Um sistema subseqente foi o WoodsVERSAO

1.0

PGINA 145

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, possibilitando 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 localizao, 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 implantao 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 Ocial:http://nfs.sourceforge.net Licena:GPL Responsvel:

Network File System [341], [245], [246], [269], sistema de arquivos distribudo desenvolvido 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 denir 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]
VERSAO

1.0

PGINA 146

G UIA DE C LUSTER

7.3.4 - N ETWORK F ILE S YSTEM - NFS

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 solues disponibilizadas parte para resolver alguns desses problemas, como um servidor de locks, chamado de Network Lock Manager [227], para auxiliar as polticas 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-onclose (aps se fechar o arquivo, este gravado em disco) para o delayed-write (o arquivo gravado em disco aps car 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 sicamente. 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 resposta do pedido de escrita ao cliente antes de realmente gravar os dados no disco, acumulando-os para escrever de uma s vez.

VERSAO

1.0

PGINA 147

G UIA DE C LUSTER

7.3.4 - N ETWORK F ILE S YSTEM - NFS

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 servidor 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 convel 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 criptograa, 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 especicao do protocolo NFSv3, foi criada uma nova verso que rev vrios conceitos que no estavam presentes nos protocolos 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 prprio protocolo NFS, sem a necessidade de servidores externos (como o NLM). O
VERSAO

1.0

PGINA 148

G UIA DE C LUSTER

7.3.4 - N ETWORK F ILE S YSTEM - NFS

mecanismo para isso baseado em leases, ou seja, um cliente NFS pede ao servidor 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 modicar o arquivo dentro do seu cache local sem a necessidade 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 compostas, ou seja, uma mesma chamada RPC pode conter uma operao complexa envolvendo bloqueio, abertura, leitura, etc. Essas chamadas so realizadas atravs de conexo TCP, ao contrrio das verses mais antigas, que usam UDP. Em relao segurana, o NFSv4 possui mecanismos sosticados, e todas as implementaes de clientes obrigatoriamente devem t-los. Dentre esses mecanismos esto inclusos Kerberos 5 e SPKM3, juntamente com o tradicional AUTH SYS [160]. Alm disso, uma nova API foi criada para permitir estender esse mecanismo 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 codicao UTF-8. Por m, todos os protocolos NFS existentes (tais como stat, NLM, mount, ACL e NFS) convergem para uma nica especicao, proporcionando uma melhor compatibilidade com os rewalls de rede, alm de introduzir no protocolo suporte 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
VERSAO

1.0

PGINA 149

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 simplicado e frgil, permitindo que clientes no conveis pudessem acessar arquivos de maneira desonesta. Isso foi resolvido na verso 4 do protocolo, onde mecanismos avanados de segurana e autenticao foram incorporados. 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 nal, 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 especicao 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 Ocial: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 distribudo para o ambiente acadmico de ensino e pesquisa, que ofereceria a cada professor e aluno uma estao de trabalho com um sistema operacional compatvel com o UNIX BSD. Alm disso, a partir de qualquer um desses computadores,
VERSAO

1.0

PGINA 150

G UIA DE C LUSTER

7.3.5 - A NDREW F ILE S YSTEM - AFS

o usurio deveria ter a mesma viso do sistema. Essa transparncia de localizao 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 desenvolvedores iriam enfrentar era a segurana. Com tantos clientes e usurios, era praticamente impossvel conar em todos sem provocar uma fragilidade na segurana de todo o sistema. O ANDREW sofreu modicaes 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 realizasse 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 eciente. Ecincia ganha com o uso de algoritmos melhores para manuteno da consistncia do cache, alm de uma melhoria na implementao da resoluo de nomes, comunicao e estrutura dos servidores. Funcionou desde o nal de 1985 at meados de 1989. O AFS-2 [245] trouxe o conceito de callback, que permite ao cliente abrir e fechar 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 cpia 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
VERSAO

1.0

PGINA 151

G UIA DE C LUSTER

7.3.5 - A NDREW F ILE S YSTEM - AFS

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 importncia 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 disponibilidade, 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 ANDREW 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 clientes e servidores, resolvendo assim o problema de segurana no acesso aos dados. A proteo dos arquivos baseada em listas de controle de acesso, que especicam quais usurios, ou grupos, tm que tipo de acesso sobre eles. Alm disso, a partir dessa implementao os arquivos deixaram de ser cacheados em sua totalidade e passaram a ser transferidos, conforme a necessidade, 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 m de atingir seus objetivos, foram adotadas algumas regras para o desenvolvimento 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, evitando sobrecarregar o servidor; 2. Sempre que possvel usar o cache para diminuir o trfego dos dados e a carga dos servidores;
VERSAO

1.0

PGINA 152

G UIA DE C LUSTER

7.3.5 - A NDREW F ILE S YSTEM - AFS

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 escalabilidade de todo o sistema capacidade dessa mquina central; 5. Conar no menor nmero possvel de entidades (segurana); 6. Agrupar o trabalho sempre que possvel. Por exemplo, realizar uma leitura de 50 KB muito mais eciente 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 diretrios armazenada nos servidores. Deste modo, a manuteno dos clientes trivial e a uniformidade do espao de nomes uma consequncia natural da congurao 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 ock, que administra bloqueios ao arquivo, de forma emulada. O responsvel 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 visite: http://www-3.ibm.com/software/stormgmt/afs/library/.
VERSAO

1.0

PGINA 153

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 primeira verso. Pensando-se sempre em escalabilidade, transparncia de localizao 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 semntica 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 dividido 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 Ocial: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 desconectadas ao sistema de arquivos para computadores portteis, que costumam car 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 replicao no presentes no AFS, dado que ele foi criado para lidar com estaes de trabalho portteis ou que permanecem conectadas aos servidores por curtos pe4

http://www.coda.cs.cmu.edu/doc/html/index.html
1.0 PGINA 154

VERSAO

G UIA DE C LUSTER

7.3.6 - C ONSTANT D ATA AVAILABILITY - CODA

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 gura 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 atualizao enviada para todos os servidores AVSG usando um mecanismo denominado 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 atualizar 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 servidores 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

VERSAO

1.0

PGINA 155

G UIA DE C LUSTER

7.3.6 - C ONSTANT D ATA AVAILABILITY - CODA

para atualizao dos arquivos que possuem rplicas inconsistentes so os prprios clientes. Essa replicao aumenta a disponibilidade dos arquivos, o que aumenta a segurana 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 permite 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 entre eles. Isso pode gerar perda de informao e acesso a dados inconsistentes quando, por exemplo, dois usurios alteram o mesmo arquivo em parties diferentes.

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 arquivo 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 comunicao com os servidores possvel sempre que necessrio, mas o cliente
5

http://www.coda.cs.cmu.edu/doc/html/kernel-venus-protocol.html
1.0 PGINA 156

VERSAO

G UIA DE C LUSTER

7.3.6 - C ONSTANT D ATA AVAILABILITY - CODA

procura estar preparado para o caso de uma desconexo da rede, seja voluntria 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, disponibilizando 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 responsveis, os arquivos em seu cache que sofreram alteraes. Aps o nal dessa operao, volta-se ao primeiro estado.

Desempenho

Alguns testes [327] realizados em situaes normais de uso mostraram que o tamanho 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 conitos na reintegrao, so raros, dado que 99% das alteraes dos arquivos 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 sistema de arquivos distribudo de alta disponibilidade. Por exemplo, ele permite que um usurio dena 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.
VERSAO

1.0

PGINA 157

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 tambm 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 Ocial: http://www.lustre.org/ Licena: GPL Responsvel(eis): Cluster File Systems, Inc

Lustre um sistema de arquivos distribudos de cdigo aberto, largamente utilizado em clusters de grande porte. O projeto tenta prover um sistemas de arquivos 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 arquivos 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 administrar 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 apenas delega esta responsabilidade a OSSs para assegurar escalabilidade a grandes clusters e supercomputadores.
VERSAO

1.0

PGINA 158

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 desempenho sob grande demanda e concorrncia de acesso. Como essa no uma tarefa fcil, os projetistas acabam no se preocupando tanto com a transparncia 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 Ocial: 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 plataforma tem crescido muito. Hoje em dia encontra-se todo tipo de software para o ambiente de computao paralela, como sistemas operacionais conveis, sistemas 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 arquivos 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 necessidade de recompil-los;
VERSAO

1.0

PGINA 159

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 aglomerado, 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 sistema como um todo, especialmente o kernel. Assim, possvel acessar os arquivos do PVFS usando uma API (Application Programming Interface) disponibilizada como biblioteca, que contm operaes comuns, alm de outras especcas do PVFS, que contactam diretamente os servidores, evitando acessos ao kernel local. Essas bibliotecas, como a ROMIO MPI-IO [360], podem ser usadas pelas aplicaes ou por outras bibliotecas para acesso de alta velocidade ao PVFS.

Os componentes do PVFS

O servidor de meta-dados (MGR na gura 7.7) um programa que gerencia todos os dados que constituem informaes sobre o arquivo (exceto seu contedo), como seu nome, sua localizao na hierarquia de diretrios, seu dono, seus atributos e como seus dados esto distribudos entre os vrios ns de dados do sistema. Esse programa realiza todas as operaes sobre os meta-dados dos arquiVERSAO

1.0

PGINA 160

G UIA DE C LUSTER

7.4.1 - Parallel Virtual Filesystem Version 1 - PVFS

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 gura 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 signica 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 convel para todo o sistema. Os servidores do PVFS no possuem estado, da mesma forma que o NFS, o que simplica sua implementao, que no considera casos como quando um cliente se desconecta da rede sem aviso prvio. Isso pode gerar problemas de consistncia, pois o servidor pode no conter a verso mais recente do arquivo (caso o cliente possusse um cache sujo), ou algum arquivo pode car 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 gura 7.8(a). Para acesso aos dados dos arquivos, o servidor de meta-dados deixado de lado e os servidores de dados

VERSAO

1.0

PGINA 161

G UIA DE C LUSTER

7.4.1 - Parallel Virtual Filesystem Version 1 - PVFS

so acessados diretamente, conforme gura 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 gura 7.9 mostra como o uxo de dados passa por esses componentes.

Figura 7.9: Fluxo de dados pelo kernel

VERSAO

1.0

PGINA 162

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 especcas desse sistema que possibilitam um ajuste no 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 sosticado. Outro problema existente quando o servidor de meta-dados ca 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 conveis, 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 Ocial: http://www.pvfs.org Licena: GPL/LGPL Responsvel(eis): Argonne National Laboratory e Clemson University

PVFS2 uma reimplementao das melhores caractersticas da primeira verso


VERSAO

1.0

PGINA 163

G UIA DE C LUSTER

7.4.2 - Parallel Virtual Filesystem Version 2 - PVFS2

do PVFS, usando uma nova arquitetura para torn-lo mais exvel. Isso possibilitou a implementao de novas caractersticas, tcnicas e inovaes que foram sendo discutidas e requisitadas durante as correes de defeitos da primeira verso. 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 aglomerados de computadores existentes hoje, nota-se que existem muitas tecnologias diferentes em cada um deles, sendo que algumas so mais populares que outras. 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 personalize mdulos especcos para seu ambiente, sem ter que alterar o ncleo do PVFS2. Acesso a dados estruturados no-contnuos Muitas aplicaes cientcas 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
VERSAO

1.0

PGINA 164

G UIA DE C LUSTER

7.4.2 - Parallel Virtual Filesystem Version 2 - PVFS2

o desempenho na leitura dos dados persistidos. Distribuio de dados exvel No PVFS1 os dados so distribudos entre os servidores de dados usando o algoritmo 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 armazenados. Isso muito eciente como uma tcnica genrica para quando no se conhece o padro de acesso ao arquivo. Porm, em geral sabe-se qual o padro 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 melhor forma de armazenar os dados para mxima ecincia, 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 representar 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 eciente quanto a prover 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 nalizao 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,
VERSAO

1.0

PGINA 165

G UIA DE C LUSTER

7.4.2 - Parallel Virtual Filesystem Version 2 - PVFS2

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 permite que o usurio opte por uma semntica mais estrita, para permitir a implementao do ROMIO MPI-IO, ou mais relaxada, permitindo um uso mais amplo. Mapeamento exvel de referncias de arquivos para servidores E possvel recongurar os servidores de meta-dados para escolher onde armazenar 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 signica 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 dados. Alm disso, o servidor de meta-dados nico. No PVFS2, cada servidor
VERSAO

1.0

PGINA 166

G UIA DE C LUSTER

7.4.2 - Parallel Virtual Filesystem Version 2 - PVFS2

pode atuar tanto como servidor de meta-dados como tambm de dados. A denio do papel que cada um vai representar est no arquivo de conguraes, lido durante a inicializao. Alm disso, pode-se ter mltiplos servidores de metadados. Redes Como j mencionado, utilizando-se o BMI, possvel que o PVFS2 se comunique por TCP/IP, InniBand 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, representado pelo cliente do sistema operacional, ou ROMIO MPI-IO. Ambas as formas seguem o mesmo perl 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 congurao do sistema de arquivos. Esse processo 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 inconsistncias entre servidor e clientes.
VERSAO

1.0

PGINA 167

G UIA DE C LUSTER

7.4.2 - Parallel Virtual Filesystem Version 2 - PVFS2

Quanto consistncia do cache, o PVFS2 permite colocar no cache do cliente a estrutura de diretrios do servidor de meta-dados. Isso pode gerar inconsistncias temporrias, pois caso haja alguma mudana em tal estrutura, o cliente car desatualizado por um certo tempo (congurvel). 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 interrompida.

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 especcas a criar mdulos robustos para o PVFS2, que permitem usar esse SAP em cada vez mais aglomerados de computadores.
VERSAO

1.0

PGINA 168

Captulo 8 Cluster de Aplicao


Um cluster de aplicao um conjunto de servidores que respondem coletivamente 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.

VERSAO

1.0

PGINA 169

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 sistemas com alta disponibilidade e altamente escalveis, a partir do uso conjunto de vrios servidores. A arquitetura totalmente transparente para o usurio nal, servios providos por um conjunto de mquinas so acessados atravs de um nico servidor. O LVS pode oferecer servios de maior capacidade/desempenho, 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 modicaes para kernel Linux, que combinadas com as capacidades de roteamento e ltragem de pacotes de uma mquina Linux, transformam-na em um roteador 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 mquina Linux com o cdigo IPVS e as outras mquinas que hospedam os servios chamado Linux Virtual Server (LVS), vide gura 8.1. O sistema LVS no necessita de nenhuma modicao nos Servidores Reais (que podem estar interconectados na mesma LAN ou geogracamente 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
VERSAO

1.0

PGINA 170

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 escalvel de alta disponibilidade. Seu ponto nico de falha (ponto crtico) o Director, mas mesmo assim, em conjuno com outras ferramentas (como Heartbeat e LDirectord) pode-se construir um sistema de alta-disponibilidade para o Director, aumentando ainda mais sua conabilidade 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 especcos para designar os componentes do sistema, segue a descrio de alguns deles:
VERSAO

1.0

PGINA 171

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 especiais 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 requisies de clientes. . Mtodos de Redirecionamento (LVS-Nat, LVS-DR, LVS-Tun) - Sendo o Director um roteador com regras especcas 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)
VERSAO

1.0

PGINA 172

G UIA DE C LUSTER

8.1.2 - T IPOS DE C LUSTER LVS

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 congurao 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 gura 8.2.

Figura 8.2: LVS-NAT

Propriedades de LVS-NAT

. Os Servidores Reais devem estar na mesma subrede do Director,


VERSAO

1.0

PGINA 173

G UIA DE C LUSTER

8.1.2 - T IPOS DE C LUSTER LVS

. 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 congurado para atender a demanda, embora uma rede saturada normalmente seja o problema mais comum.

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 zeram 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) congurada com o VIP que no responde a requisies ARP, redirecionando as conexes 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 balanceador 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.
Software de roteamento da IBM usado para balancear carga entre servidores TCP, mais informaes podem ser obtidas em: http://www.cs.princeton.edu/courses/archive/
1

fall03/cs518/papers/networkdispatch.pdf
VERSAO

1.0

PGINA 174

G UIA DE C LUSTER

8.1.2 - T IPOS DE C LUSTER LVS

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 diretamente 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 colocados dentro de outros pacotes IP, permitindo que pacotes destinados a um determinado endereo IP sejam redirecionados para outro endereo. Neste mtodo de congurao de LVS o Director e os Servidores Reais no necessitam estar no
VERSAO

1.0

PGINA 175

G UIA DE C LUSTER

8.1.3 - A LGORITMOS DE ESCALONAMENTO

mesmo segmento de rede, mesmo estando geogracamente 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 diretamente 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 mtodos de escalonamento para o balanceamento de carga. Os mtodos de escalonamento regulam a maneira como a carga distribuda entre os ns que compem
VERSAO

1.0

PGINA 176

G UIA DE C LUSTER

8.1.3 - A LGORITMOS DE ESCALONAMENTO

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 especco, 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 quantidade 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 maiores tero prioridade no recebimento e quantidade de requisies, se comparados com Servidores Reais com pesos menores.
VERSAO

1.0

PGINA 177

G UIA DE C LUSTER

8.1.3 - A LGORITMOS DE ESCALONAMENTO

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 verica 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 mtodo padro se nenhum for selecionado), til para ser usado com ns de diferentes 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 denida no algoritmo utilizada para realizar a distribuio da carga.


1.0 PGINA 178

VERSAO

G UIA DE C LUSTER

8.1.3 - A LGORITMOS DE ESCALONAMENTO

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 nalizao. O tempo de espera (Ci + 1)/U i, sendo Ci o nmero de conexes do servidor e Ui o peso xado 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 mquina que no possua nenhuma conexo ativa apresente um overhead maior que outra que possua.
VERSAO

1.0

PGINA 179

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 servidores proxy transparentes. Nesta congurao, os ns do cluster so proxy transparentes 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 endereo 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 Servidor Real para atend-la usando um verso um pouco modicada do mtodo WLC e todas as requisies subseqentes deste cliente continuaro a ser enviadas para o servidor escolhido.

Locality-Based Least-Connection with Replication Scheduling (LBLCR)

semelhante ao mtodo anterior com uma melhoria, o Director mantm um mapeamento 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 modicar em um intervalo de tempo especco (seis minutos, intervalo padro como denido 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 capacidade 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 listados abaixo. Mais casos de uso podem ser encontrados em http://www. linuxvirtualserver.org/deployment.html.

VERSAO

1.0

PGINA 180

G UIA DE C LUSTER

8.2 - C LUSTER T OMCAT

Stio
http://linux.com http://sourceforge.net http://themes.org http://wwwcache.ja.net http://www.zope.org www.songn.com

Forma de utilizao Balanceamento de carga HTTP Balanceamento de carga HTTP, HTTPS, FTP, SSH, CVS Balanceamento de carga HTTP 40 servidores Squid em 3 clusters LVS Balanceamento de carga HTTP Um Director rodando em modo VS/DR 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 sistema computacional. O servidor de aplicaes responde questes comuns todas 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 ocialmente endossado pela Sun como a Implementao de Referncia (RI) para as tecnologias Java Servlet e JavaServer Pages (JSP). O Tomcat , sucientemente, robusto e eciente para ser utilizado em ambientes de produo. Tecnicamente o Tomcat um container Web, cobrindo parte da especicao 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 (capacidade de atender ao aumento de requisies de usurios atravs do aumento do nmero de servidores fsicos) e alta disponibilidade (capacidade de suportar
VERSAO

1.0

PGINA 181

G UIA DE C LUSTER

8.2 - C LUSTER T OMCAT

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 estejam 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 disponibilidade, caso um dos ns que compem o sistema caia, as requisies de usurios continuam a ser tratadas de maneira transparente.

VERSAO

1.0

PGINA 182

G UIA DE C LUSTER

8.2 - C LUSTER T OMCAT

Figura 8.5: Viso geral de um cluster Tomcat

O modelo bsico para clusterizao em Tomcat envolve o uso de duas camadas adicionais (gura: 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.
VERSAO

1.0

PGINA 183

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.

VERSAO

1.0

PGINA 184

G UIA DE C LUSTER

8.2.1 - B ALANCEAMENTO DE CARGA

Figura 8.6: Balanceamento de carga via DNS Round-Robin

Em servidores DNS congurados para prestar este tipo de servio, um endereo (ex. www.seudominio.com) resolvido para os IPs dos servidores que hospedam 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 conhecido 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 processador, conexes ativas no servidor, entre outros. Isso minimiza a sobrecarga dos servidores alm disponibilizar os servios hospedados nestas mquinas atravs 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 processador 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 complexidade de congurao e o fato de constituirem um ponto nico de falha.
VERSAO

1.0

PGINA 185

G UIA DE C LUSTER

8.2.1 - B ALANCEAMENTO DE CARGA

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 Tomcat que no estejam respondendo. . Caso uma instncia deixe de responder, mod_jk2 verica periodicamente se ela voltou, caso a instncia volte a responder ela posta junto com as outras instncias 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 Roundrobin 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 assegura que todas as requisies com mesma sesso sero tratadas pelo mesmo n Tomcat. A desvantagem desde mtodo que caso uma instncia deixe de funcionar, a sesso associada a ela ser perdida. Balanceamento de carga via software
VERSAO

1.0

PGINA 186

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. Classicado como um roteador de camada 4, trata-se de modicaes 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 especializado. 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 redirecionada. 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 conexes 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 camada, mostrada na gura 8.5, serve a outro propsito, assegurar que sesses e outras informaes no sejam perdidas caso o servidor Tomcat, que as manipulavam, caia. Na camada de compartilhamento, mostrada na gura 8.5, podem ser usados alguns tipos de back-ends, cada qual com suas funcionalidades. O compartilhamento de informaes nesta camada pode assegurar que a perda de conectividade 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 congurao, o balanceador de carga mod_jk2 assegura que as requisies de uma mesma sesso sero sempre tratadas pela mesma instncia Tomcat. Este tipo de congurao conveniente a muitos cenrios de produo,
VERSAO

1.0

PGINA 187

G UIA DE C LUSTER

8.3 - H EARTBEAT

apresentando as seguintes caractersticas:

. Escalabilidade para a aplicao provida por algoritmo Round-robin, que cria novas sesses no prximo n livre na la round-robin. . Simplicidade de implantao e manuteno. . Nenhum tipo de congurao 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 modicadas por todas as instncias. Isto tambm garante uma menor 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 conabilidade,
3

stio do projeto: http://www.linux-ha.org/


1.0 PGINA 188

VERSAO

G UIA DE C LUSTER

8.4 - Z OPE C LUSTER

disponibilidade e suportabiidade (serviceability) atravs do esforo de uma comunidade de desenvolvimento. O Heartbeat, fruto deste projeto, um software que gerencia falhas de recursos entre dois computadores, procurando eliminar pontos nicos de falhas aumentando 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 vericar se ainda esto ativos. Normalmente o Heartbeat trabalha com os conceitos de servidor primrio e secundrio, ou seja, um servidor que de fato atende a demandas (primrio) e outro que ca 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 servidores especicado; 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 vericao do estado de cada n, o Heartbeat pode usar uma ou mais conexes fsicas, podendo ser a conexo ethernet normal para comunicaes de rede, interfaces dedicadas ligadas por cabo crossover ou atravs de cabo serial. A conexo 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 segurana e tambm por ser usada apenas para esse m.

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 geralmente 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
VERSAO

1.0

PGINA 189

G UIA DE C LUSTER

8.4 - Z OPE C LUSTER

de aplicao, que composto, tipicamente, por trs partes distintas: um servidor HTTP, um banco de dados e alguma aplicao (middleware) que serve de interface 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 rodar mltiplas instncias de Zope em um nico computador ou em vrios computadores, acrescentando escalabilidade ao sistema, j que, para atender ao possvel (e muito provvel) aumento de demanda, mais mquinas podem ser acrescentadas ao sistema, alm do aumento de conabilidade, caso uma mquina apresente problemas as outras ativas podero atender a requisies at que a falha seja resolvida. 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, geogracamente, 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 resolvido 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
VERSAO

1.0

PGINA 190

G UIA DE C LUSTER

8.4 - Z OPE C LUSTER

o uso de ferramentas externas. Vrios mtodos podem ser utilizados para distribuir 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 roundrobin para distribuir as requisies recebidas por uma URL entre vrios IPs de uma rede interna, sendo cada nova requisio enviada para um servidor diferente da anterior. Sendo idntico o contedo de todos os servidores, esse processo transparente para o usurio. Contudo, esta uma soluo atraente por sua simplicidade entretanto apresenta seus reveses; por exemplo, arquivos de diferentes 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

VERSAO

1.0

PGINA 191

G UIA DE C LUSTER

8.4 - Z OPE C LUSTER

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 especico resolvido para apenas um IP que pertence ao roteador que por sua vez, transparentemente, redireciona 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, Heartbeat 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 verica o estado de sanidade dessas mquinas, tomando providencias necessrias (reincio, noticao 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 servidores ZODB.

VERSAO

1.0

PGINA 192

G UIA DE C LUSTER

8.4 - Z OPE C LUSTER

Figura 8.9: ZEO/ZODB + LVS+OCFS2

VERSAO

1.0

PGINA 193

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 obter 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 signicativos para consultas e atualizao 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

VERSAO

1.0

PGINA 194

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 alocao 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 car muito grandes, envolvendo milhares de parques computacionais heterogneos. Como novos bancos de dados podem ser adicionados/removidos do sistema, ca mais difcil para o processador de consulta" manter estatsticas precisas das relaes participantes armazenadas nos diferentes sites e das operaes de consulta relacionadas. Tambm, como a carga de trabalho dos vrios servidores de processamento e a velocidade de transmisso dos links entre eles utuam 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 maximizam 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 conrmadas. Conitos 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, ca mais fcil realizar o bloqueio, entretanto os problemas devem ser conhecidos anteriormente para diminuir os custos de rollbacks.
VERSAO

1.0

PGINA 195

G UIA DE C LUSTER

CAPTULO 9 : C LUSTER DE B ANCO DE D ADOS

Processamento de Transaes.

Transaes distribudas provem unidades de execuo segura que permitem que vrias operaes sejam executadas em locais diferentes e provem a preservao da consistncia dos dados de um estado de execuo para outro. Um protocolo 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 denio de mecanismos de compensao. Replicao de Dados.

O desao fundamental na replicao de dados manter um baixo custo nas atualizaes enquanto se assegura a consistncia dos parques computacionais do cluster. A diculdade do problema aumenta signicativamente 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 eciente, ao custo de uma baixa garantia da consistncia global dos dados.

Integrao de Dados.

Conitos diferentes surgem da representao descoordenada de conceitos ao se integrar fontes de dados autnomas e distribudas. Exemplos destes conitos
VERSAO

1.0

PGINA 196

G UIA DE C LUSTER

CAPTULO 9 : C LUSTER DE B ANCO DE D ADOS

so: tipo de dados, estrutura, conito de nomes, atributos perdidos, e conitos de generalizao. Todos estes conitos 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 componente 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 global.

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 cam 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 aplicao que controla a distribuio e replicao dos dados. Vantagem: Pode ser
VERSAO

1.0

PGINA 197

G UIA DE C LUSTER

CAPTULO 9 : C LUSTER DE B ANCO DE D ADOS

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 poucos 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 interna do prprio sistema de banco de dados. Vantagem: Possui maior integrao com o sistema de banco de dados, sistema mais robusto de integridade 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 sistema 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 requisio como se o banco no estivesse em cluster. Aps a escrita ter sido armazenada em disco todos os outros servidores sero capazes de reconhecer 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 denir qual a melhor tecnologia a ser adotada para cada situao.
VERSAO

1.0

PGINA 198

G UIA DE C LUSTER

9.1 - B ANCO DE D ADOS D ISTRIBUDOS

9.1 Banco de Dados Distribudos


Denies

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 controle 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 sicamente atravs de mltiplos locais. Um banco de dados distribudo dividido em vrias partes ou fragmentos. 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, existem vrias outras tecnologias para design de banco de dados distribudos. Por exemplo, autonomia local, tecnologias de bancos de dados distribudos sncronos e assncronos. A implementao destas tecnologias podem e denitivamente dependem das necessidades das reas de negcios e de a sensibilidade e condenciabilidade 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 cpias distribudas em uma ou mais mquinas. Este tipo de sistema oferece
VERSAO

1.0

PGINA 199

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 propagao de uma atualizao. Uma primeira aproximao chamada replicao sncrona, ou seja uma atualizao (modicao 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 signica que o cliente ter de esperar at que todas as instncias do banco de dados sejam modicadas para receber uma conrmao, garantindo a integridade da informao entre os ns. A outra aproximao realizar a atualizao de maneira assncrona, ou seja as modicaes so difundidas entre os ns aps ser efetivada em um servidor 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 diferentes. Todas as operaes de modicao no banco sero enviadas para esta mquina que cuidar de propagar as modicaes. A contrapartida para este modelo permitir atualizaes em qualquer banco que componha o sistema, no introduzindo uma rplica privilegiada mas requerendo um sistema que resolva conitos de possveis inconsistncias. O uso de middleware (software interface entre os clientes e o sistemas de bancos de dados) se tornou um atrativo, j que permite a construo de sistemas replicados sem a necessidade de modicao do sistema de gerenciamento de banco de dados, nem no banco de dados em si. Em sistemas desta natureza as requisies so enviadas ao middleware que se encarrega de propaglas 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 corporativo, o Mysql[13] e o Postgresql[19], dos quais veremos alguns detalhes sobre a clusterizao e replicao de dados.
VERSAO

1.0

PGINA 200

G UIA DE C LUSTER

9.3 - P OSTGRE SQL

9.3

PostgreSQL

O PostgreSQL um SGBD (Sistema Gerenciador de Banco de Dados) objetorelacional de cdigo aberto, com mais de 15 anos de desenvolvimento. extremamente robusto e convel, alm de ser extremamente exvel e rico em recursos. Ele considerado objeto-relacional por implementar, alm das caractersticas de um SGBD relacional, algumas caractersticas de orientao a objetos, como herana e tipos de dados personalizados. A equipe de desenvolvimento do PostgreSQL sempre teve uma grande preocupao em manter a compatibilidade com os padres SQL92/SQL99/SQL2003 (Postgresql-BR [19]). As capacidades de Replicao e Clusterizao so feitas atravs de middlewares 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 adicionalmente salva as conexes com os servidores PostgreSQL por ele coordenados (PGpool atualmente trabalha apenas com dois servidores PostgreSQL), reutilizando-as quando uma nova conexo com mesmas propriedades (nome de usurio, banco de dados, protocolo) chega, reduzindo sobrecarga de conexo e aumentando a taxa de transferncia de todo o sistema. 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
VERSAO

1.0

PGINA 201

G UIA DE C LUSTER

9.3.1 - PG POOL

nenhum mtodo para voltar um servidor com problemas de novo no cluster, sendo necessrio que os bancos sejam sincronizados novamente. A melhor maneira desativar o servidor ativo, sincronizar os arquivos do Postgresql 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 (desempenho) 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 operao 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 congurao 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 PostgreSQL, PGpool abortar a sesso se um dos ns no responderem por um certo intervalo de tempo congurvel. Para propsitos de balanceamento de carga (congurvel pelo parmetro load_balance_mode" no arquivo de congurao), as consultas SELECT"so distribudas entre o n master e o slave de maneira aleatria, para aumentar performance. importante notar que mesmo instrues SELECTpodem introduzir alteraes em bancos chamando funes que podem modic-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 modicaes na aplicao. . Qualquer linguagem pode ser usada. . O nmero de conexes com o PostgreSQL pode ser limitado.
VERSAO

1.0

PGINA 202

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 distribudas 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 password"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 recompilao 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-denido. Uma regra de particionamento denida por funes SQL e so armazenadas no System DB", que outro servidor PosgreSQL. A arquitetura do PGpool-II ilustrada na gura 9.1 que se segue.
VERSAO

1.0

PGINA 203

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 modicaes para o cdigo fonte do PostgreSQL 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 garante 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 encaminha 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 armazena as consultas em bancos de dados. . servidor de replicao (Replicator): cuida de manter os dados sincronizados 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:
VERSAO

1.0

PGINA 204

G UIA DE C LUSTER

9.3.2 - PG CLUSTER

. Balanceamento de carga: Pela combinao de servidores de armazenamento e servidor de replicao, pode-se criar um sistema onde o PGCluster vericar qual mquina est com menor carga, redirecionando uma possvel consulta para ela. . Alta disponibilidade: Com a adio de um balanceador de carga, PGCluster congura 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 armazenamento e servidor de replicao, PGCluster pode distribuir carga de acesso ao banco de dados, vericando qual mquina est com menor carga, redirecionando consultas para ela. A gura 9.2 ilustra a estrutura de balanceamento de carga.

Figura 9.2: Sistema de balanceamento de carga

Sistema de Alta disponibilidade Adicionalmente, PGCluster pode prover um sistema de Alta Disponibilidade pela adio de um balanceador de
VERSAO

1.0

PGINA 205

G UIA DE C LUSTER

9.3.2 - PG CLUSTER

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 gura 9.3 ilustra a estrutura de Alta Disponibilidade para o PGcluster. Quando uma mquina que falhou recolocada no sistema, os dados so copiados para ela automaticamente, o mesmo acontecendo quando um servidor de armazenamento novo adicionado.

Figura 9.3: Sistema de alta disponibilidade

VERSAO

1.0

PGINA 206

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 congurao mude de maneira aleatria. . Sistemas onde schemas de bancos de dados podem ser mudados arbitrariamente. 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
VERSAO

1.0

PGINA 207

G UIA DE C LUSTER

9.4 - M YSQL

usando triggers para coletar as atualizaes, onde uma origem comum replicada 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 Language - Linguagem Estruturada para Pesquisas) muito rpido, multi-tarefa e multi-usurio. O Servidor MySQL pode ser usado em sistemas de produo 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 diculdades 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 causar inconsistncias de dados, j que tabelas podem estar sendo modicadas enquanto o backup feito. O problema de inconsistncia poderia ser resolvido 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 conveis mantendo disponvel o sistema a replicao do MySQL. A replicao uma congurao onde um servidor MySQL, conhecido neste contexto como master, armazena dados e gerencia as conexes dos clientes 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. Entre as vantagens da replicao esto a facilidade de backup e recuperao, alm de dar melhor suporte a grandes aplicaes. possvel se conseguir
VERSAO

1.0

PGINA 208

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 congurao 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 slaves. As consultas SELECT podem ser enviadas aos slaves para reduzir a carga do processamento de consultas no master. Declaraes que impliquem em modicaes 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 processos 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 identica sua posio no log. O servidor slave, com certa freqncia, verica 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 identicao posicional em um arquivo (master.info). O slave, ento, volta a vericar 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 gravada no log de erro do slave (error.log). Se o resultado for satisfatrio (os dados estiverem corretos), um novo nmero de identicao de log gravado 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 signicativamente o master, alm de assegurar replicao convel, sendo tambm muito simples de congurar, signicando algumas poucas linhas
VERSAO

1.0

PGINA 209

G UIA DE C LUSTER

9.4.1 - R EPLICAO EM M Y SQL

adicionais ao arquivo de congurao 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 comeando de um ponto xo a partir do momento em que este log foi habilitado no servidor. Qualquer slave precisar de cpias das bases de dados do master exatamente como existiam no momento em que o log binrio foi iniciado, de outra forma a replicao falhar. Aps ser congurado, o servidor slave conecta ao master e espera por atualizaes. Se o master cair ou a conexo for perdida, o slave continuar tentando se conectar periodicamente at que seja capaz de receber informaes sobre modicaes. 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 indicando 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.
VERSAO

1.0

PGINA 210

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 modicaes no banco de dados prefervel usar log baseado em coluna. Uma thread que realiza updates em vrias colunas com uma clusula WHERE deve usar log baseado em declarao por ser mais eciente gravar no log poucas declaraes que muitas colunas. . Algumas declaraes requerem muito tempo de execuo no master, mas resultam em poucas colunas modicadas. Deve ento, ser benco replic-las utilizando-se log baseado em coluna. H algumas excees para as quais no se pode mudar o modo de replicao 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 temporariamente 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 baseada em coluna elas no sero gravadas no log. Com replicao mista, tabelas temporrias so usualmente gravadas no log, excees para os casos de funes denidas pelo usurio (UDF) e a funo UUID().

9.4.2

MySQL Cluster

MySQL cluster tecnologia que habilita clusterizao de bancos de dados em memria sem dependncia de hardware ou tecnologia especca. MySQL Cluster implementa uma arquitetura distribuda, altamente tolerante a falhas com nenhum ponto nico de falha (SPOF), recuperao automtica de ns garantindo a conabilidade de um mainframe em hardware de baixo custo, constituindo uma soluo de alta disponibilidade com excelente custo benefcio. O sistema integra um servidor MySQL padro com componente para armazenamento clusterizado em memria chamado NDB, consistindo de
VERSAO

1.0

PGINA 211

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 congurada com muitas opes de tolerncia a falhas e balanceamento de carga. Cada parte do MySQL cluster congurada independentemente dos servidores MySQL, sendo que cada parte considerada um n1 . H trs tipos de ns e em uma congurao 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 congurao, iniciar e parar outros ns, backup entre outras coisas. Deve ser o primeiro a ser iniciado pois gerencia a congurao 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 tradicional que usa a engine de armazenamento NDB. Num ambiente real de produo, a congurao com trs ns no inclui redundncia. Para se beneciar 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 documentao 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.

VERSAO

1.0

PGINA 212

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, transparentemente, um cluster de banco de dados atravs de JDBCTM . No necessrio realizar modicaes nas aplicaes clientes, nas aplicaes servidoras ou no servidor de banco de dados. Basta apenas que os banco de dados sejam acessados pelo Sequoia. O Sequoia um projeto livre de cdigo aberto, continuao do projeto C-JDBC (http://c-jdbc.obejctweb.org) hospedado pelo projeto ObjectWeb Consortium (http://www.objectweb.org). Sequoia liberado sob a licena Apache v2 (www.apache.org/licenses/LICENSE-2.0.html) enquanto CJDBC 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 desenvolvimento 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.
1.0 PGINA 213

VERSAO

G UIA DE C LUSTER

9.5.1 - M IDDLEWARE S EQUOIA

. 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 la do banco de dados tornase 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 balaneamento 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 na 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 exvel 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.
VERSAO

1.0

PGINA 214

G UIA DE C LUSTER

9.5.1 - M IDDLEWARE S EQUOIA

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 customizaes como agendadores de requisies, balanceadores de carga, gerenciadores 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 signicando que seu uso (pessoal ou comercial) livre de qualquer taxa. Se voc estiver usando um SGBD comercial (Oracle,DB2,...), haver os custos das licenas adicionais para ns extras nos
VERSAO

1.0

PGINA 215

G UIA DE C LUSTER

9.5.1 - M IDDLEWARE S EQUOIA

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 suciente para uma boa performance.

Quais modicaes so necessrias

Voc no necessita de qualquer mudana em sua aplicao ou seu banco de dados. necessria, apenas, a atualizao da congurao do driver JDBC usado por sua aplicao (usualmente apenas a atualizao de um arquivo de congurao) e os ajustes no arquivo de congurao 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 conabilidade que excedem as capacidades de um disco de grande capacidade. RAIDb visa melhor 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 workstations e bancos de dados de cdigo aberto. Clusters de workstations j so alternativa vivel se comparadas s mquinas paralelas usadas em pesquisa cientca pela vantajosa relao custo/benecio. Clusters desta natureza podem ser usados para prover alta disponibilidade e escalabilidade em ambientes de bancos de dados. RAIDb esconde a complexidade da replicao disponibilizando ao cliente atraVERSAO

1.0

PGINA 216

G UIA DE C LUSTER

9.5.1 - M IDDLEWARE S EQUOIA

vs da viso de acesso a um nico banco de dados, utilizando-se uma mquina (controller) que colocada frente dos recursos disponveis. Os cliente direcionam 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 tolerncia a falhas. . RAIDb-1: para replicao e espelhamento completo. . RAIDb-2: que oferece replicao parcial.

Tambm esto denidos, RAIDb-1ec e RAIDb-2ec que adicionam vericao de erros aos nveis RAIDb-1 e RAIDb-2, respectivamente.

RAIDb-0: Com este nvel de RAIDb pode-se particionar o banco de dados, distribuindo 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 congurao requer no mnimo dois backends, provendo escalabilidade de performance mas sem tolerncia a falhas. A gura 9.5 mostra um exemplo de congurao RAIDb-0.

Figura 9.5: Exemplo de RAIDb-0

VERSAO

1.0

PGINA 217

G UIA DE C LUSTER

9.5.1 - M IDDLEWARE S EQUOIA

RAIDb-1 RAIDb-1 oferece espelhamento completo com replicao total dos bancos de dados nos backends. Este modelo de congurao 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 vericao de erros ao RAIDb-1, objetivando deteco de erros bizarros. Requerendo ao menos 3 ns, esta congurao envia as requisies de escrita para a maioria dos ns que compem o cluster e as resposta so comparadas. Se h consenso nas respostas, elas so enviadas aos clientes, caso contrrio uma mensagem de erro enviada em resposta a requisio. A gura 9.6 mostra um exemplo da congurao RAIDb-1.

Figura 9.6: Exemplo de RAIDb-1

RAIDb-2 RAIDb-2 a combinao de RAIDb-0 e RAIDb-1, provendo replicao 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 modelo requer que cada tabela esteja disponvel em pelo menos 2 ns. Tambm implementa vericao de erro como RAIDb-1ec. Opera com um mnimo de 4 ns sendo que 3 deles conguram quorum para resposta. A escolha dos ns tambm mais complexa que em RAIDb-1ec dada a possibilidade de replicao parcial, embora esta caracterstica garanta uma melhor performance. A gura 9.7 mostra um exemplo desta congurao.
VERSAO

1.0

PGINA 218

G UIA DE C LUSTER

9.5.1 - M IDDLEWARE S EQUOIA

Figura 9.7: Exemplo de RAIDb-2

Nveis de RAIDb aninhados possvel utilizar vrios nveis de RAIDb ao mesmo tempo para se congurar grandes sistemas ou atender necessidades especcas. Um controlador RAIDb escala um nmero limitado de bancos de dados, 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 sistema 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 controladores podem ser usados para atender s requisies. O middleware de comunicao de grupo JGroups usado para sincronizar as modicaes nos bancos de maneira distribuda. Os bancos de dados no necessitam ser compartilhados entre os controladores, mas caso um controlador caia, os bancos associados a ele tambm caro indisponveis. No caso de backends compartilhados, um controlador enviar as requisies aos backends informando ao outro controlador assim que as requisies estiverem completadas. A gura9.8. mostra um exemplo de uma congurao RAIDb-1-0. O ltimo exemplo (gura 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.
VERSAO

1.0

PGINA 219

G UIA DE C LUSTER

9.5.1 - M IDDLEWARE S EQUOIA

Figura 9.8: Exemplo de RAIDb-1-0

Figura 9.9: Exemplo de RAIDb-0-1

Balanceamento de carga

O balanceador de carga dene a maneira que as requisies sero distribudas entre os backends de acordo com o nvel do RAIDb. possvel reforar um nvel de isolamento especco para todas as conexes (isto no ter efeito se o banco de dados usado no suporta isolamento de transaes). Em geral, o nvel de isolamento 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.


VERSAO

1.0

PGINA 220

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 paralelos, como Oracle Parallel Server ou Middle-R. Ambas, escrita e leitura, so balanceadas entre os backends, deixando a replicao paralela dos bancos escrever. . RAIDb-0: particionamento completo de banco de dados (nenhuma tabela pode ser replicada) com poltica opcional que especca onde novas tabelas sero criadas. . RAIDb-1: espelhamento completo de banco de dados (todas as tabelas so replicadas em qualquer lugar) com poltica opcional que especca como a consumao 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 vericao 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 consumo de consultas distribudas (como em RAIDb-1). . RAIDb-2ec: replicao parcial (como RAIDb-2) com vericao 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 ecincia consultas pesadas que envolvam grandes quantidades de dados, usando para isso, o SGBD PostgreSQL sobre clusters de PCs. No ParGRES, o processamento da consulta explora o paralelismo intrae inter-consultas, usando replicao e fragmentao virtual de dados. O paralelismo do ParGRES voltado para as consultas pesadas tpicas de aplicaes OLAP e proposta uma soluo para essa demanda atravs da implementao de paralelismo intra-consulta em um cluster de Banco de Dados. O paralelismo intra-consulta signica decompor consultas complexas em sub-consultas que sero executadas em paralelo. A idia que cada sub-consulta atue em um
VERSAO

1.0

PGINA 221

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 caracterstica especca 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.

VERSAO

1.0

PGINA 222

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 baratos. O projeto foi criado por Donald Becker 1 da NASA, e hoje so usados em todo mundo, principalmente para programao cientca. 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 informaes 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
VERSAO

1.0

PGINA 223

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 dena 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 processamento 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 congurao deste ambiente existem 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 complexidade dos sistemas distribudos, permitindo que os mesmos paream uma nica mquina ao usurio. Logo desta maneira os fatores como a heterogeneidade do hardware implementado no ser problema para o seu funcionamento, e questes como a gerncia e utilizao efetiva dos recursos sero facilmente solucionadas. 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 muitas vezes, um incremento de recursos em tempo de execuo, dependendo da escalabilidade suportada. Pode tambm assegurar que o sistema continue funcionando aps alguma falha em um ou alguns de seus ns sem que haja perdas
VERSAO

1.0

PGINA 224

G UIA DE C LUSTER

10.2.1 - A S P RINCIPAIS C ARACTERSTICAS DE UM C LUSTER SSI

considerveis, permitindo que o cluster que sempre disponvel para as aplicaes 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 efetivo, 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 apresenta 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 ca acima da camada do sistema operacional e por uma camada de infraestrutura de imagem nica que ca 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 eciente 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 apresentada pelas requisies de cada usurio de forma transparente ao mesmo.
VERSAO

1.0

PGINA 225

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 grca de usurio, tal como uma pgina web onde se possam usufruir os servios associados ao cluster. Essa interface deve possuir 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 processos. 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 espao nico de memria, de forma que os diversos espaos locais dos inmeros 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 aplicao 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 transparente ao usurio. Fazendo assim um nico espao de endereamento formado 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 identiquem 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
VERSAO

1.0

PGINA 226

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, congurados e monitorados atravs de um nico conjunto de interfaces grcas tais como uma pgina web. Migrao de processos e checkpointing: deve-se fazer periodicamente a gravao das informaes dos processos tais como estado e processo ou em memria ou em disco, garantindo em caso de falha do mesmo sua continuao 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 execuo no cluster; Exclui do usurio a necessidade de apontar onde se deve executar tal aplicao; Garante o uso de recursos independentemente da proximidade fsica aos mesmos; Permite maior facilidade para gerenciamento do sistema pelo administrador 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 conabilidade ao sistema;
VERSAO

1.0

PGINA 227

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 sistema por pessoas, sem que essas tenham elevado conhecimento sobre a arquitetura 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 aumentar a complexidade e qualidade de seus sistemas. Promove a padronizao de ferramentas para o seu controle e administrao.

10.2.3 Memria Distribuda Compartilhada - DSM


Tcnica utilizada para compartilhamento de memria fsica dos ns, dando a iluso 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 lgica, 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 especialmente 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 localizados 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 cpias, permitindo que qualquer processador que acesse a memria compartilhada devolva a informao correta, sendo a comunicao e a sincronizao feita atravs da prpria memria.
VERSAO

1.0

PGINA 228

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, cando esses caches com a funo de buffers temporrios, para que no se desperdice ciclos do processador. Quando um programa feito, existe uma ordem especica 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 mdulos de grande valia ao servio de clustering: um patch para memria compartilhada 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 processamento 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 comandos SQL. Os processos forked" se anexam ao processo MySQL principal que
VERSAO

1.0

PGINA 229

G UIA DE C LUSTER

10.2.4 - O PEN M OSIX

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 memria. 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 lho, o processo recm-criado apenas precisa inicializar 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 apache, 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 openMosix tais como o apache, entre outros. Checkpointing" uma tcnica que prov a possibilidade de se salvar contextos 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 interrompidos. 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 Eugeny S. Meshcheryakov no Information and Computing Center do National Taras Shevchenko University em Kyiv, Ucrnia. O CHPOX usa uma abordagem de mdulo de kernel, logo ele pouco relacionado verso do kernel atual e dinamicamente inserido e removido do espao de kernel. Devido sua integrao com o Mosix/openMosix, o CHPOX se tornou rapidamente aceito pela comunidade openMosix. Tecnologia openMosix

VERSAO

1.0

PGINA 230

G UIA DE C LUSTER

10.2.4 - O PEN M OSIX

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 compartilhado 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 multicomputador 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 eciente alocao e compartilhamento de recursos. A qualquer momento que um processo seja inicializado, nalizado, ou mude seu perl 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 atividades. Ao contrrio do SMP, Clusters Computacionais (CC) so feitos de colees de servidores (at mesmo SMPs) e workstations que sicamente nada compartilham, com diferentes velocidades e quantidades de memria, possivelmente de diferentes geraes. Na maioria das vezes, CCs so utilizados para ambientes timesharing" 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 cooperao entre os ns consideravelmente limitada pois a maioria dos servios do sistema operacional so localmente connadas 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 adaptao da aplicao e o conhecimento do usurio. Eles incluem ferramentas para alocao inicial (xa) de processos para ns, os quais algumas vezes utilizam consideraes sobre a carga, enquanto ignoram a disponibilidade de outros recursos tais como memria livre e overheads" de E/S. Esses pacotes cam na camada de usurio, assim como as aplicaes comuns, entretanto so incapazes de responder a mudanas no nvel de carga ou mesmo de outros recursos, ou at de

VERSAO

1.0

PGINA 231

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 existem vrios tipos diferentes de recursos, tais como CPU, memria, E/S, IPC (Comunicao InterProcessos), etc, onde cada recurso utilizado de uma maneira diferente e na maior parte das vezes seu uso imprevisvel. Outras diculdades surgem do fato que diferentes usurios no coordenam suas atividades. Entretanto 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 ecincia, 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 recursos, 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 signicativas perdas de performance devido a cargas mal distribudas. O openMosix um conjunto de algoritmos que juntos suportam compartilhamento 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 globalmente, e distribuir o workload" dinamicamente e de forma eciente acaba por simplicar 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.
VERSAO

1.0

PGINA 232

G UIA DE C LUSTER

10.2.5 - K ERRIGHED

As metas do Kerrighed so alto desempenho de aplicaes, alta disponibilidade do cluster, administrao de recursos ecientemente, alta poder de customizao do sistema operacional e facilidade de uso. Kerrighed implementado como uma extenso a sistema operacional GNU/Linux (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 escalonadores 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 uxo de alta performance. Podem ser migrados processos que usam uxos (socket, pipe, fo, char device, etc) sem penalidade no desempenho de comunicao depois de migrao. 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. Vericao de processos. Os processos podem ser vericados 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
VERSAO

1.0

PGINA 233

G UIA DE C LUSTER

10.2.5 - K ERRIGHED

Unix (top, ps, kill, etc) so operados pelo cluster. Alm disso, os identicadores de processos (pid) so nicos no cluster. Caractersticas customizveis da imagem nica de sistema. As caractersticas do SSI (memria compartilhada, escalonador global, migrao de uxos, 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 processador, essa aplicao poder rodar mais rpido com o Kerrighed. Se a aplicao no roda mais rpido em uma maquina com vrios processadores, 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 funcionalidades 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.

VERSAO

1.0

PGINA 234

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 programador 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 programa 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 primitivas semelhana de send e receive. As bibliotecas de comunicao que obtiveram maior aceitao foram: MPI (Clarke [121]) e PVM (Geist [166]), ambas com
VERSAO

1.0

PGINA 235

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 funcionamento de um conjunto de mquinas mono/multi-processadas e/ou paralelas, como um nico recurso computacional paralelo. Com a utilizao do PVM consegue-se uma forma eciente e transparente de distribuir tarefas entre mquinas ligadas em rede, conseguindo um bom desempenho na gerencia dos recursos computacionais, atravs da congurao 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 otimizada, aos ns que compem o ambiente paralelo; apresenta uma interface de programao intuitiva e consistente; oferece suporte para tolerncia falhas, monitorao e proling e altamente portvel".

Com isso, atravs da agregao e compartilhamento de processadores e memrias de computadores heterogneos, problemas que exigem grande poder computacional podem ser resolvidos sem a necessidade de comprar um supercomputador. Assim, utilizar o PVM uma forma de aumentar o desempenho, com um custo efetivo menor.
VERSAO

1.0

PGINA 236

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 vericao e manuteno de estado da mquina virtual, esto contidas nessa biblioteca. Os programas paralelos que utilizam o PVM fazem uso das rotinas disponibilizadas na biblioteca de interface do PVM. Para programao, essas bibliotecas so distribudas em linguagens como Java, Python, Perl, alm das linguagens tradicionais como C, C++ e Fortran. Ao utilizar uma aplicao PVM, o usurio executa o pvmd3 em um dos computadores 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 transmisso 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 especco.
VERSAO

1.0

PGINA 237

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, pertencentes a 40 instituies, principalmente dos Estados Unidos e Europa. A maioria dos fabricantes de computadores paralelos participou, de alguma forma, da elaborao do MPI, juntamente com pesquisadores de universidades, laboratrios e autoridades governamentais. O incio do processo de padronizao aconteceu no seminrio sobre Padronizao para Troca de Mensagens em ambiente de memria distribuda, realizado pelo Center for Research on Parallel Computing, 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 preliminar, foi realizado por Dongarra, Hempel, Hey e Walker, em novembro 1992, sendo a verso revisada nalizada 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 conferncia Supercomputing 93, realizada em novembro de 1993, do qual se originou a verso ocial do MPI (5 de maio de 1994). Ao nal 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 SuperComputing96 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 entre os processos. Inicialmente, na maioria das implementaes, um conjunto xo
VERSAO

1.0

PGINA 238

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 programas. Por isso, o padro MPI algumas vezes referido como MPMD (multiple program multiple data). Elementos importantes em implementaes paralelas so a comunicao de dados entre processos paralelos e o balanceamento da carga. Dado o fato do nmero de processos no MPI ser normalmente xo, 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 operaes coletivas (collective) de comunicao para executar operaes globais. O MPI capaz de suportar comunicao assncrona e programao modular, atravs de mecanismos de comunicadores (communicator) que permitem ao usurio MPI denir mdulos que encapsulem estruturas de comunicao interna. Os algoritmos que criam um processo para cada processador podem ser implementados, 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 renamento nas implementaes com o MPI.

11.2 Relaes Entre o Hardware e o Software para Explorao 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 paralelas.
VERSAO

1.0

PGINA 239

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 algoritmo 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 quanticar a natureza das relaes.

Critrios para Caracterizao de Algoritmos

O critrios que sero utilizados para caracterizar o perl 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 contm. relativamente usual existir abundncia de paralelismo com baixa granulosidade, o qual, via de regra, no pode ser explorado com ecincia. 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 (dataow), conVERSAO

1.0

PGINA 240

G UIA DE C LUSTER

11.2.1 - R ELAO ENTRE A LGORITMOS E A RQUITETURAS PARALELAS

Algoritmo Paralelo Granulosidade do mdulo Controle da concorrncia Mecanismo de dados Geometria das comunicaes Tamanho do algoritmo

Arquitetura Paralela Complexidade do processador Modo de operao Estrutura da memria Rede de interconexo 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 processadores sistlicos ou outros processadores matriciais (SIMD). Por sua vez, algoritmos que incorporam transferncias condicionais ou outras irregularidades no uxo 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 dados (dataow), ou podem ser colocados em um lugar de armazenamento, e ento referenciados pelo seu endereo, como no modelo de Von Neumann e suas extenses. 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 geometrias 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 considerado um problema grande. O tamanho do algoritmo diz respeito ao nmero de processadores e disponibilidade de memria da arquitetura paralela.

VERSAO

1.0

PGINA 241

G UIA DE C LUSTER

11.2.1 - R ELAO ENTRE A LGORITMOS E A RQUITETURAS PARALELAS

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 interna de cada elemento de processamento. Sistemas cujos processadores tem capacidade idntica so ditos homogneos. Aqueles sistemas cujos processadores so diferentes, ou so direcionados para realizar funes especcas, 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 armazenados. Em processadores matriciais (SIMD), alguma memria precisa estar associada ao elemento de processamento. Em multiprocessadores, por sua vez, cada nodo de processamento pode incorporar memria local, memria cache, e gerenciamento de memria. A complexidade do processador est associada granulosidade do algoritmo. Arquiteturas de gro-elevado tem poucos processadores bastante poderosos; um exemplo tpico 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 FX8, cada cluster com oito processadores. Uma arquitetura de gro-no utiliza um grande nmero de processadores pequenos. Uma representante tpica desta arquitetura 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-uxo (command-ow), assim chamado porque a seqncia de eventos controlada por comandos derivados do uxo de instrues. Outro mtodo disparar as operaes medida que os seus operandos tornam-se disponveis, de acordo com o modelo comandopor-dados (dataow); neste caso, o controle determinado pela disponibilidade dos dados. Outra alternativa de controle ainda, o comando-por-demanda (demand-ow), no qual as computaes ocorrem somente se seus resultados so solicitados por outras. possvel a combinao destes modos de controle. O modo
VERSAO

1.0

PGINA 242

G UIA DE C LUSTER

11.2.1 - R ELAO ENTRE A LGORITMOS E A RQUITETURAS PARALELAS

de operao da arquitetura relacionado com o modo de controle da concorrncia do algoritmo. Estrutura da memria: refere-se ao modo de operao e organizao da memria do hardware paralelo. A memria pode ser acessada utilizando tanto endereos 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 indica 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 comunicaes do algoritmo paralelo. Computadores paralelos com redes de interconexo simples e/ou xas conseguem ser ecientes para um determinado conjunto de tipos de algoritmos. Redes de interconexo complexas, ao contrrio, podem ser conguradas 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 recongurvel dinamicamente. Nmero de processadores e tamanho da memria: indica quantos processadores o sistema paralelo contm, e o tamanho da memria disponvel. Para a tecnologia 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 necessrio 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 armazenados. O particionamento de algoritmos pode introduzir efeitos colaterais
VERSAO

1.0

PGINA 243

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 otimizado 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 Processamento 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 suciente 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 ecientemente 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 gura 11.1 resume esta proposta. Nesta seo sero discutidos os aspectos de um modelo ideal para o desenvolvimento de software paralelo. A organizao adotada foi proposta em SKILLICORN [333]. Os recursos mnimos que este modelo deve oferecer so os seguintes:
VERSAO

1.0

PGINA 244

G UIA DE C LUSTER

11.2.2 - P ROPRIEDADES DE UM M ODELO DE P ROGRAMAO PARA O P ROCESSAMENTO PARALELO

Facilidade para o Desenvolvimento do Software

Os aspectos pertinentes ao controle da execuo paralela so bastante complexos. Na medida do possvel, o modelo deve retirar do programador a responsabilidade sobre os mesmos. Para tanto, deve car 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 executadas concorrentemente pelos diversos processadores da arquitetura. Isto implica em fracionar o cdigo e a estrutura de dados em partes, cujo nmero e tamanho so funo das caractersticas da arquitetura; mapeamento das tarefas paralelas aos processadores. Uma vez que o programa tenha sido dividido, se faz necessria a deciso de em qual processador ser alocada cada tarefa. Um dos principais critrios para deciso o volume de comunicaes, de tal forma que tarefas com volume de comunicaes 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 signicativo para o desempenho levar em conta as caractersticas do processador no momento da alocao de uma determinada tarefa; 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 especca de atuao do mecanismo dependente da arquitetura, porm indispensvel que as tarefas paralelas que trocam dados tenham suporte para tal, evitando atrasos no processamento em funo de dados que custam a vir, ou que eventualmente nem mesmo viro; sincronizao entre as tarefas paralelas. relativamente usual no processamento paralelo, duas ou mais tarefas precisarem conrmar se todo o grupo j atingiu determinado ponto comum da computao. Neste caso, tambm a especicidade do mecanismo que ser utilizado fortemente dependente da arquitetura. O tema sincronizao bastante amplo e complexo. Existe
VERSAO

1.0

PGINA 245

G UIA DE C LUSTER

11.2.2 - P ROPRIEDADES DE UM M ODELO DE P ROGRAMAO PARA O P ROCESSAMENTO PARALELO

na relao entre comunicao e sincronizao um grande potencial para inconsistncias 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 entre a informao a ser disponibilizada pelo programador e a necessria para execuo 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 anlise dos possveis estados da computao paralela que seu uso efetivo praticamente invivel; a equipe de desenvolvimento teria acesso apenas a algumas das arquiteturas paralelas nas quais o software poderia vir a ser executado. Este aspecto ca 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 dicultam a reproduo exata de execues, como por exemplo o no determinismo inerente maioria das redes de interconexo.

Como a comprovao do comportamento dos possveis estados do software paralelo aps seu desenvolvimento, se mostra complexo demais para uso prtico, somente um processo, que leve na direo de um software correto por metodologia de construo, colocar o desenvolvimento de software em um patamar de segurana e conforto razoveis (vide item 5.1.8).
VERSAO

1.0

PGINA 246

G UIA DE C LUSTER

11.2.2 - P ROPRIEDADES DE UM M ODELO DE P ROGRAMAO PARA O P ROCESSAMENTO PARALELO

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 modicaes 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 desenvolvedores, 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], somente 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, considerando o custo das comunicaes, podem introduzir custo computacional elevado. Assim, somente modelos que limitem a freqncia das comunicaes, podem esperar ter uma garantia mnima de desempenho em diferentes hardwares
VERSAO

1.0

PGINA 247

G UIA DE C LUSTER

11.2.2 - P ROPRIEDADES DE UM M ODELO DE P ROGRAMAO PARA O P ROCESSAMENTO PARALELO

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 reexos 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 paralelo. 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 especco que ser utilizado. Na programao paralela tal situao no ocorre; pequenas modicaes no programa ou a troca do hardware paralelo podem mudar completamente 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 nmero de processadores); informaes a respeito do tamanho dos dados de entrada (no os seus valores);

No texto SKILLICORN [333], tambm caracterizada a importncia de considerar 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.
VERSAO

1.0

PGINA 248

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 programao 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 Abstrao e Modelos


O objetivo deste captulo caracterizar a potencialidade para explorao do paralelismo em diferentes modelos de programao. A classicao utilizada tem como critrio o nvel de abstrao com que a explorao pode ser feita. Estes nveis de abstrao esto sugeridos em SKILLICORN [333] e BAL [74]. A partir de textos especcos 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 paralelismo no so necessariamente mais complexos que os elaborados para execuo seqencial. Como exemplos caractersticos deste nvel de abstrao na explorao do paralelismo, destacam-se a programao funcional e a programao em lgica.
VERSAO

1.0

PGINA 249

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 declarativa, na qual o programa denido 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 ausncia de efeitos colaterais (side-effects) entre as sub-expresses de uma funo; isto faculta uma anlise paralela das mesmas, sem riscos de dependncias de dados e/ou controle, JONES [238]. Um clssico programa que ilustra a possibilidade de avaliao paralela de subexpresses o algoritmo recursivo de Fibonacci: Como as duas chamadas recursivas de bonacci so independentes, podem ser executadas em paralelo. Fonte Implcita de Paralelismo A tcnica utilizada para linguagens funcionais puras (de alta ordem e sem anotaes) denominada reduo de grafo (Graph Reduction), PEYTON-JONE [300]. As funes so expressas como rvores, com sub-rvores comuns (para representar as sub-funes compartilhadas). A computao consiste em selecionar subestruturas 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.
VERSAO

1.0

PGINA 250

G UIA DE C LUSTER

11.3.1 - M ODELOS NOS QUAIS O PARALELISMO E XPLORADO DE F ORMA T OTALMENTE I MPLCITA

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 difcil gerenciar a distribuio de carga entre processadores, o total de novas tarefas criadas e o volume de comunicaes. Segundo HANUS [210], a explorao totalmente 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 paralelismo com programao funcional, tem obtido desempenho razovel em equipamentos com memria compartilhada, no conseguindo boa ecincia 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 imperativas, elas no permitem atribuies destrutivas s variveis, nem controle explcito do uxo de execuo do programa. Isto confere s linguagens de programao em lgica, uma semntica clara (declarativa) e uma decorrente construo 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 uxo 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 executadas em qualquer ordem (no determinismo), sem que com isto seja afetada a consistncia de execuo do mesmo.
VERSAO

1.0

PGINA 251

G UIA DE C LUSTER

11.3.1 - M ODELOS NOS QUAIS O PARALELISMO E XPLORADO DE F ORMA T OTALMENTE I MPLCITA

Fontes Implcitas de Paralelismo Existem duas principais fontes de paralelismo implcito na programao em lgica (KERGOMMEAUX [244]): Paralelismo OU: este tipo de paralelismo refere-se a uma estratgia de busca paralela na rvore de metas do programa lgico. Assim, quando o processo de busca encontra uma ramicao na rvore de metas, ele pode iniciar processos paralelos de busca em cada ramo descendente (vide gura 11.3). O nome paralelismo 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 gura 11.3), o paralelismo E corresponde construo paralela de uma ramicao. 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 unicao. O paralelismo disponibilizado de baixa granulosidade e, para ser explorado com ecincia, exige hardware especializado. O paralelismo E, por sua vez, pode ser explorado entre literais independentes (sem possibilidade de conito na atribuio de valores a variveis), ou entre quaisquer literais, s custas de um mecanismo mais complexo de deteco e gerncia 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 momento, trabalhando de forma independente, sobre um ramo especco da rvore de busca.
VERSAO

1.0

PGINA 252

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.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 independncia a nvel de compilao com um eciente ambiente de execuo implementado 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 compilador 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. Potencialidade de Explorao do Paralelismo As alternativas de explorao do paralelismo na programao em lgica so fortemente ortogonais entre si; isto signica que podem ser explorados simultaneamente, sem que um comprometa o outro. O paralelismo OU, presente em programas com no determinismo, caracteriza-se
VERSAO

1.0

PGINA 253

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 equipamentos 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 diculta 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 diculta 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 alternativas de paralelismo possveis. O custo-benefcio da explorao implcita do paralelismo ainda no atingiu patamares 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, ca 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 destino e dos decorrentes custos de escalonamento, comunicao e sincronizao.
VERSAO

1.0

PGINA 254

G UIA DE C LUSTER

11.3.2 - M ODELOS COM A SSINALAMENTO DO PARALELISMO E XPLCITO

Como exemplo de paralelismo neste nvel de abstrao temos explorao do paralelismo de dados.

Paralelismo de dados - explorao de laos

O paralelismo de dados tem uma origem histrica no uso de processadores pipeline. Neste caso, a explorao de paralelismo ocorria com a aplicao de forma independente e repetida de uma mesma operao sobre dados diferentes. Tal situao permitia o uso de processadores com registradores vetoriais, com os quais o paralelismo era explorado, associado a um custo reduzido de controle das repeties. Com o desenvolvimento das arquiteturas matriciais (SIMD), as mesmas se tornaram timas candidatas para processar em paralelo o cdigo vetorizado. Por sua vez, o cdigo para arquiteturas matriciais pode ser ecientemente 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 organizadas na forma de matrizes de dimenses variadas (estruturas regulares), e o paralelismo se viabiliza quando estes dados so passveis de manipulao independente. Esta manipulao independente comum na lgebra matricial. Exemplo de Explorao do Paralelismo 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 paraleVERSAO

1.0

PGINA 255

G UIA DE C LUSTER

11.3.2 - M ODELOS COM A SSINALAMENTO DO PARALELISMO E XPLCITO

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. Potencialidade de Explorao do Paralelismo O cdigo para explorao do paralelismo de dados simples de ser escrito e depurado. Isto decorre do paralelismo ser explicitamente trabalhado pelos sincronismo e uxo 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 determinante para o seu desempenho. Portanto, este paralelismo centrado em computaes locais e operaes de manipulao de dados (replicaes, permutaes, redues, etc.). Pode ser explorado 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 ecientemente o paralelismo a nvel de instruo. O paralelismo de dados, tem sido utilizado com timos desempenhos em diversas arquiteturas. A simplicidade do seu cdigo facilita a codicao e eventuais recodicaes quando de migraes entre arquiteturas diferentes. Faculta uma previso de desempenho e tambm medida de custo. Porm, possvel sua explorao com desempenho somente quando os dados tiverem as caractersticas de independncia e regularidade mencionadas.

VERSAO

1.0

PGINA 256

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 Paralelismo 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 programa. Existem poucas propostas neste nvel de abstrao (somente duas), e sua implementao ocorre na forma de bibliotecas utilizadas a partir das linguagens C e FORTRAN. Como exemplo deste nvel de abstrao, surge a explorao do paralelismo com restrio de comunicaes e sincronizao.

Exemplo de Explorao do Paralelismo

Um modelo que explora o paralelismo neste nvel o BSP (Bulk Synchronous Parallelism 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. Enquanto isto, de forma independente, a rede de interconexes realiza as trocas de dados necessrias entre os processadores. Ao nal 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 localmente. 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 propriedades da rede de interconexo utilizada na arquitetura paralela a partir de uns poucos parmetros. A mquina abstrata do BSP consiste de uma coleo de
VERSAO

1.0

PGINA 257

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 paralelo. 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 complexidade 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 atualizaes de dados por comunicaes globais.

Potencialidade de Explorao do Paralelismo

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 previsibilidade inuenciada pelos seguintes fatores: Comunicaes: a otimizao das comunicaes depende de como ocorre a alocao (automtica) das threads aos processadores, tendo em vista as caractersticas
VERSAO

1.0

PGINA 258

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 utilizado (sua granulosidade, possibilidade de ser particionado em partes homogneas, 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 Mapeamento do Paralelismo Explcitos

Nestes modelos, o programador, alm de dividir o programa em partes, tem a incumbncia de avaliar qual o melhor processador para cada parte. Uma vez que a proximidade dos processadores determinante para o desempenho das comunicaes, indispensvel para o programador ter conhecimento das caractersticas da rede de interconexes utilizada na arquitetura. Este comprometimento do cdigo 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.
VERSAO

1.0

PGINA 259

G UIA DE C LUSTER

11.3.4 - M ODELOS COM A SSINALAMENTO , D ECOMPOSIO E M APEAMENTO DO PARALELISMO E XPLCITOS

Exemplo de Explorao do Paralelismo

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 informados 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.

Potencialidade de Explorao do Paralelismo

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 especicar comunicaes introduz um custo elevado no desenvolvimento do software paralelo. Os modelos que operam neste nvel de abstrao reduzem muito este custo, oferecendo primitivas de alto nvel para especicao das trocas de dados. Normalmente esta simplicao feita separando, nos programas, os aspectos de processamento dos de comunicao. Normalmente disponibilizada uma linguagem a parte (subconjunto da linguagem) para tratar das comunicaes. Esta diviso faz com que a computao e a comunicao quem 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 paraleVERSAO

1.0

PGINA 260

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 car 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 ecincia 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, Mapeamento e Comunicao Explcitos


Nestes modelos, o programador tem a seu encargo especicar quase todos os detalhes da implementao paralela, exceto os aspectos pertinentes a sincronizao. Para oferecer isto, via de regra, estes modelos empregam uma semntica assncrona, na qual as mensagens so enviadas, porm o emissor no ca atrelado ao tempo necessrio para que elas atinjam seu destino.

Exemplo de Explorao do Paralelismo

O mais importante modelo nesta classe Atores (Actors - AGHA [47]). Ele consiste 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 outros atores que ele conhece e a partir das mensagens que chegaram dene 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.
VERSAO

1.0

PGINA 261

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].

Potencialidade de Explorao do Paralelismo

Alm dos custos de comunicao, outro ponto de estrangulamento (gargalo) do desempenho do modelo de atores o processamento seqencial das mensagens na la 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 desempenho 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 especicar todos os aspectos da implementao. 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.

Exemplo de Explorao do Paralelismo

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
VERSAO

1.0

PGINA 262

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 destrutiva, comandos de controle de repetio, comandos de seleo simples e mltipla, procedimentos, etc. Para explorao do paralelismo SR fornece mecanismos especcos 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 computadores (mquinas fsicas). Os processos residentes em um mesmo espao de endereamento podem compartilhar memria. Desta forma, a linguagem SR suporta programao em ambientes distribudos e ambientes com memria compartilhada. 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 comunicao entre processos de recursos remotos pode ser feita atravs de troca de mensagens assncronas, chamada remota de procedimentos (RPC) e rendezvous.

Potencialidade de Explorao do Paralelismo

De forma anloga a outros modelos de sua categoria, a linguagem SR no oferece recursos de abstrao para deteco, decomposio, comunicao ou sincronizao 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.

VERSAO

1.0

PGINA 263

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 las de processamento (batch queue manager") que prioriza e controla a execuo de mltiplas tarefas. Job schedulers" so tambm, conhecidos como gerenciadores de distribuio de recursos ou gerenciadores de las de execuo. As caractersticas bsicas esperadas de um job scheduler" so:

Interface para se denir o uxo 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 las 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.
VERSAO

1.0

PGINA 264

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 inicializao ou o seqenciamento de execuo de grupos de tarefas, e permitir a distribuio destes trabalhos entre vrios ns de um cluster. O sistema de controle de tarefas (batch server) permite que sejam denidas 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 componentes: um servidor, clientes e comandos de usurios. O servidor gerencia diferentes objetos, como tarefas e las 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 modicar 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 executados), assim como, as las e as tarefas. Ele prov servios como: criao, execuo,
VERSAO

1.0

PGINA 265

G UIA DE C LUSTER

12.2 - TORQUE

modicao, excluso e roteamento de tarefas para os clientes (ns computacionais) 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 sobre 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 signicativas 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 desenvolvimento 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
VERSAO

1.0

PGINA 266

G UIA DE C LUSTER

12.3 - MAUI

processos); Capacidade de suportar grande nmero e tamanho de mensagens de servidores.

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 caractersticas 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 capacidade de congurao em diversas reas como: priorizao de tarefas, seqenciamento, alocao, distribuio de cargas e polticas de reserva de recursos. MAUI foi projetado com base em experincias coletivas dos maiores e mais avanados centros de HPC do mundo. Ele prove ferramentas que estes centros precisavam para controlar, rastrear e otimizar o uso de seus recursos. Uma coleo extensiva de estatsticas e ferramentas de perl, 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 conguraes foram feitas de forma segura.
VERSAO

1.0

PGINA 267

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 alguns outros gerenciadores de recursos. As principais caractersticas do Crono so:

Possui um bom nvel de congurao, 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 exvel para atender demanda especca 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 arquitetura, 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 alocados para usurios da grade e cam 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).

VERSAO

1.0

PGINA 268

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 geogracamente 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 impossvel 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 servios 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 caractersticas especcas de Grids para alto desempenho.

13.1 Introduo
Grids Computacionais so atualmente uma das reas mais quentes da Computao. O que comeou em universidades e institutos de pesquisa ganhou o
VERSAO

1.0

PGINA 269

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 Computacionais guram hoje como um assunto em moda. Porm, o que anal vem a ser um Grid Computacional? A viso original estabelece 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 transparente 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-

VERSAO

1.0

PGINA 270

G UIA DE C LUSTER

13.1 - I NTRODUO

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 sosticado. 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 Desempenho, motivada pela idia de se utilizar computadores independentes e amplamente 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 servios e recursos, e utilizando mecanismos que facilitem a interoperabilidade. Os atrativos desta idia incluem a possibilidade de fornecimento de qualquer servio computacional sob demanda, o qual pode ser composto dinamicamente por outros servios e agregar recursos localizados em vrias instituies distintas e geogracamente 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
VERSAO

1.0

PGINA 271

G UIA DE C LUSTER

13.1 - I NTRODUO

execuo remota. O servio de execuo remota crucial porque ele introduz importantes desaos para infraestrutura do Grid. Os Grids que fornecem execuo remota tendem a ser mais complexos, pois ao permitir uma maior exibilidade 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 pertinentes 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 distribuda. 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 diferena 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. Aspectos 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 qualquer soluo para Grids Computacionais dever lidar com recursos de vrias geraes, softwares de vrias verses, instrumentos e servios dos mais variados tipos. Alta disperso geogrca: Essa caracterstica se refere a escala que um Grid pode atingir. Nesse sentido, Grids podem ter escala global, agregando servios 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
VERSAO

1.0

PGINA 272

G UIA DE C LUSTER

13.1 - I NTRODUO

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 instituies. Sendo assim, alm da heterogeneidade mencionada anteriormente, possvel tambm a existncia de vrias polticas de acesso e uso dos servios, de acordo com as diretrizes de cada domnio que faz parte do Grid. Controle distribudo: Tipicamente no h uma nica entidade que tenha poder sobre todo o Grid. Isso um reexo da disperso dos componentes do Grid, pois cada instituio pode implementar sua poltica em seus recursos 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 denio 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 desqualicar 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 ferramenta de marketing [180]. Devido a sua popularidade e a seu impacto positivo, 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 desmisticar e posicionar os esforos atuais na concretizao da viso original dos Grids Computacionais, discutiremos vrios aspectos 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, desaos que tais caractersticas sugerem e os investimentos de padronizao. Na sesso 13.3 sero apresentados as questes exclusivas a Grids para Alto Desempenho, que envolvem 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.
VERSAO

1.0

PGINA 273

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 Servios necessrio denir 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 denio como analogia, consideramos como servio computacional 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 fornea essa interface. Neste captulo discutiremos as tecnologias que permitem o desenvolvimento de infraestruturas baseadas em servios computacionais, bem como aspectos importantes 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 computacionais no uma novidade. Ou seja, o grande interesse atual da comunidade cientca e da indstria por arquiteturas orientadas a servios, bem como o crescimento 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 construo 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, introduzem um requisito que se torna fundamental: interoperabilidade.
VERSAO

1.0

PGINA 274

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 provedor deve registr-lo no RMI registry [21]. O servio identicado 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 Denition Language - IDL), que independente da linguagem em que o servio e cliente so implementados. Esse aspecto torna mais exvel que RMI, pois permite que o cliente e o servio sejam implementados em linguagens diferentes. Por exemplo, podemos ter um cliente desenvolvido em C++ e um servio escrito em Java.
CORBA

Em CORBA, um servio acessado de forma semelhante a RMI. A diferena substancial 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 transVERSAO

1.0

PGINA 275

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 desenvolvedores de dade [199].
ORB s

se tornou acirrada acarretando problemas de interoperabili-

Por outro lado, Web Services surgiu como uma nova tecnologia para computao 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 envio 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 mensagens.

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 fundamental para construir uma infraestrutura de servios sob demanda. Sendo assim, em Grids computacionais fundamental que seja possvel descoVERSAO

1.0

PGINA 276

G UIA DE C LUSTER

13.2.2 - D ESCOBERTA DE S ERVIOS

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 critrios, como classicao 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 encontrar objetos cujas propriedades atendam um determinado critrio de pesquisa. Se em um sistema CORBA, restrito a uma nica organizao, um servio de descoberta importante, o que dizer de sistemas em Grid, que executam em um ambiente multi-institucional. Eles so fundamentais para que seja possvel compartilhar recursos e servios computacionais em escala global. No contexto da Computao em Grid, os recursos compartilhados podem ser ciclos de CPU, espao 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 arquitetura 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
VERSAO

1.0

PGINA 277

G UIA DE C LUSTER

13.2.2 - D ESCOBERTA DE S ERVIOS

global de todos os Web Services compartilhados na Internet. Este catlogo organizado 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 aliado. Os registros privados, ou corporativos, so aqueles que guardam informaes de Web Services internos de uma empresa, protegido por um rewall, que devem ter seu acesso restrito s aplicaes da empresa. J os registros aliados compartilham e trocam seus dados de forma controlada com outros registros, baseado em acordos entre as instituies envolvidas. Seus Web Services esto disponveis apenas a usurios autorizados. Um exemplo de registros aliados o de Web Services sendo utilizados por aplicaes de empresas de uma holding. Cada empresa poderia ter seu prprio registro e eles juntos formarem um grupo de registros aliados, 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 informaes sobre Web Services que podem ser acessados livremente na Web. Os dados mantidos pelos registros pblicos podem ser compartilhados ou transferidos livremente 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 Services 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, fornecendo informaes que ajudam a localiz-lo no catlogo, assim como estabelecer 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 eciente, escalvel e tolerante a falhas como servio de descoberta de Web Ser-

VERSAO

1.0

PGINA 278

G UIA DE C LUSTER

13.2.2 - D ESCOBERTA DE S ERVIOS

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 Service) [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 cooperativa, para atender as consultas. A idia que quando um peer precise realizar uma consulta na rede, ele a repasse primeiramente a seus peers conhecidos. Estes por sua vez, propagam a consulta aos peers de sua prpria lista, at um limite denido 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 executor 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 falha. 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 inuencia o desempenho das consultas. No entanto, no h uma garantia de que um servio que atenda aos critrios de uma consulta seja localizado. Um resultado de consulta negativo no necessariamente signica 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 registro realizar a consulta em seus prprios ns e devolver ao registro original da consulta os resultados, que sero entregues ao executor da consulta. Esta abordagem foi originalmente adotada pelo servio Trader do CORBA. Ela aumenta a robustez, tolerncia a falhas, ecincia e escalabilidade do servio de descoberta.

VERSAO

1.0

PGINA 279

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 formao das federaes. Com o crescimento esperado do uso de Web Services e conseqentemente do servio UDDI, este parece ser o caminho natural de evoluo do servio de descoberta.

13.2.3 Autenticao e Autorizao


Na Seo 13.2.1 descrevemos como ocorre o acesso a servios usando vrias tecnologias para computao distribuda. importante ressaltar que apresentamos uma simplicao 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 ca claro que a ampla disperso 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 identicado e autenticado, em geral, para todos os recursos 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 subconjunto 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 esquemas baseados em chaves pblica e privada, bem como certicados digitais. Desta forma, cada domnio administrativo pode manter sua poltica local de autenticao 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 infraestruturas possuem uma camada que fornece uma infraestrutura de segurana para que seja possvel autenticar e autorizar o acesso e uso de servios do Grid,
VERSAO

1.0

PGINA 280

G UIA DE C LUSTER

13.2.4 - P RIVACIDADE DE D ADOS

enquanto outras usam certicados 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 desses 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 desaador em um ambiente amplamente distribudo e dinmico como o Grid. A necessidade de proteo dos dados existe por dois motivos. O primeiro se refere a possibilidade de acesso no autorizado a informaes condenciais. O segundo aspectos, est relacionado a possibilidade de sabotagem, onde outra aplicao modica os dados a serem processados a m de manipular os resultados que sero obtidos com aquela computao. A Entropia [30] prov mecanismos de criptograa 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 criptograa [114]. O problema que possvel que algum possa modicar 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 principal privacidade no utilizam uma infraestrutura to dispersa quanto o Grid. Essas aplicaes executam em ambientes controlados e proprietrios onde a privacidade pode ser garantida. Um exemplo disso foi a infraestrutura montada pela HP para prover a renderizao das imagens do lme Sherek 2 [34].
VERSAO

1.0

PGINA 281

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, prossionais e governo. Muitas vezes, para executar um servio, 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 companhias 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 m. 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 simplica muito o trabalho dos que pretendem tirar frias. Da mesma forma, no mundo da computao, quanto mais compostos forem 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 composio de novos servios. Desta forma, seu cdigo no tem que ser reimplementado. 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
VERSAO

1.0

PGINA 282

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 desaos. 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 especicao apropriada de servios compostos, precisamos de modelos que denam as vrias caractersticas da composio. Ou seja, a identicao 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: dene a estrutura dos componentes que fazem parte da composio; Modelo de orquestrao: especica a ordem em que cada componente dever ser acionado, e sobre quais condies; Dados e modelo de acesso aos dados: especica a estrutura dos dados usados na composio, bem como a forma de acesso a eles; Modelo de seleo de servio: especica como o usurio pode selecionar cada servio, e o papel que cada componente desempenha na composio; Transaes: especica o tratamento de transaes pela composio - o que deve ser feito quando uma falha ocorre durante a execuo de uma transao.

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
VERSAO

1.0

PGINA 283

G UIA DE C LUSTER

13.2.6 - D ISPONIBILIZAO DE S ERVIOS

alto nvel da especicao e riqueza de detalhes que estas linguagens permitem alcanar nas especicaes, elas tm sofrido vrias crticas da comunidade. A principal crtica diz respeito ao fato de que ao especicar a composio de servios, necessrio conhecer antecipadamente todos os servios que fazem parte da composio, bem como a ordem e condies em que cada tarefa deve ser executada. Isto torna impossvel montar novas composies em tempo de execuo, 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 aplicaes. Esta sentena bastante bvia. Contudo, ela levanta alguns problemas tcnicos no-triviais. Suponha que duas instituies A e B decidem formar um Grid, unicando 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 sosticado. Tal sosticao 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 modelos 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 aborVERSAO

1.0

PGINA 284

G UIA DE C LUSTER

13.2.6 - D ISPONIBILIZAO DE S ERVIOS

dagem que acordos de compartilhamento sosticados no so mais necessrios. Recursos so comprados e vendidos de forma independente, sem um supervisor onisciente do mercado. Desta forma, entidades podem decidir independentemente quando comprar ou vender recursos. Inicialmente, a moeda utilizada ser provavelmente algum dinheiro virtual que daria apenas poder de compra de recursos 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: provedores de servios, consumidores de servios e os servios propriamente ditos. Note que provedor e consumidor so papis que podem ser assumidos concorrentemente. Abaixo listamos e discutimos brevemente alguns modelos econmicos [99]:

Commodity Market: Provedores divulgam de forma competitiva seus servios e os respectivos preos. Consumidores decidem baseado no custo/benefcio 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 servios, onde cada um tenta maximizar o resultado de acordo com seus objetivos. 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 consumidores. Os consumidores pode modicar sua oferta (em incrementos positivos). A negociao naliza quando os consumidores param de efetuar ofertas.
VERSAO

1.0

PGINA 285

G UIA DE C LUSTER

13.2.6 - D ISPONIBILIZAO DE S ERVIOS

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 criao de um ambiente cooperativo de compartilhamento de recursos. Ou seja, provedores que contribuem tero garantida a possibilidade de consumir quando necessitarem.

A seguir, apresentaremos estratgias usadas para incentivar a participao de entidades no Grid. A idia promover a agregao de recursos de vrios domnios administrativos, com o intuito de formar um Grid que benecie os clientes de cada domnio.

GRACE

- Grid Architecture for Computational Economy

desejvel que uma soluo para o problema de incentivo participao no Grid fornea exibilidade no que se refere as polticas de compartilhamento de recursos. Ou seja, necessria a existncia de mecanismos que garantam o compartilhamento de recursos de forma escalvel. Alm disso, dever ser possvel para o cliente expressar seus requisitos, bem como os provedores expressarem as condies 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 abordagens baseadas em leilo para o mercado de energia eltrica [25]. Portanto, a introduo de modelos de compartilhamento mais sosticados, baseados em economia, promete uma infraestrutura mais exvel e poderosa para o compartilhamento de recursos e construo de Grids. Um exemplo de investimento 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:
VERSAO

1.0

PGINA 286

G UIA DE C LUSTER

13.2.6 - D ISPONIBILIZAO DE S ERVIOS

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 recursos / 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 Information 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 aplicao) 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 unicado 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 dene regras e o formato para troca de comandos entre o cliente GRACE (i.e. Trade Manager) e o provedor do servio (Trade Server).
VERSAO

1.0

PGINA 287

G UIA DE C LUSTER

13.2.6 - D ISPONIBILIZAO DE S ERVIOS

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 (provedores) ocorrer de acordo com algum modelo econmico. Uma das implementaes possveis do GRACE utiliza como broker o Nimrod/G [102]. O modelo econmico implementado foi o Posted Price Market Model descrito anteriormente [99]. Nesse caso, os vrios Trade Servers do sistema devem divulgar seus preos, de forma a atrair consumidores, esperando que os Trade Managers requisitem 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 m de controlar o compartilhamento de recursos entre sites, um grande nmero de aplicaes, 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 econmicos. 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 dicultaria sua implantao efetiva, e uma infraestrutura mais simples, o que facilitaria sua implantao, porm 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
VERSAO

1.0

PGINA 288

G UIA DE C LUSTER

13.2.6 - D ISPONIBILIZAO DE S ERVIOS

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 peerto-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 solicitar recursos. A Figura 13.5 ilustra a idia da rede de favores, onde cada peer controla um conjunto 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 baseado 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]

VERSAO

1.0

PGINA 289

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 pesquisa sobre Grids Computacionais atualmente, orientao a servios. Neste sentido, faremos tambm um breve histrico sobre os padres para arquiteturas baseadas em Grid Services e qual o estado atual desses esforos.

A viso

A experincia prtica adquirida no desenvolvimento dos Grids de alto desempenho tornou possvel identicar os problemas que dicultam 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 entendida como sendo a integrao de recursos e servios distribudos de forma transparente e eciente. Assim, foi identicado que este requisito motiva tanto a comunidade cientca como a indstria. Portanto, do lado acadmico, a crescente necessidade de cooperao cientca entre grupos geogracamente distribudos, atravs do compartilhamento de recursos e servios, do outro lado a indstria que tem como necessidade a integrao 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 conceitos Grids com web services [250]. A partir disto foi denida uma arquitetura de
VERSAO

1.0

PGINA 290

G UIA DE C LUSTER

13.2.7 - PADRONIZAO

servios bsicos para a construo de uma infraestrutura de Grids Computacionais baseados em Servios. Esta arquitetura foi denominada Open Grid Services Architecture (OGSA) [184, 53]. A denio 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 chamados de Grid Services [184]. Os grid services so essencialmente web services que seguem convenes estabelecidas na especicao da OGSA e suportam interfaces padronizadas para garantir algumas operaes adicionais, como gerenciamento do ciclo de vida do servio. As interfaces padres denidas 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 denio do modelo da arquitetura e identicao de servios bsicos atravs do padro OGSA foi necessria a especicao do comportamento desses servios. Sendo assim, o passo seguinte foi a especicao dessa infraestrutura servios bsicos, no intuito de permitir a implementao do modelo da arquitetura denida pela OGSA. A nova especicao foi denominada Open Grid Services Infrastructure (OGSI) [368] e tem o objetivo de denir as interfaces bsicas e os comportamentos de um Grid Service [53]. OGSI a materializao da arquitetura denida pelo padro OGSA, pois os servios especicados servem como base para construo dos Grids. Em termos prticos, a especicao OGSI dene:

Um conjunto de extenses para a linguagem tion Language).

WSDL

(Web Service Descrip-

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 referenciar um servios.
VERSAO

1.0

PGINA 291

G UIA DE C LUSTER

13.2.7 - PADRONIZAO

Formato para mensagens que indicam falhas, sem modicar o modelo de mensagens de falha da linguagem WSDL. Conjunto de operaes que permitem a criao e destruio de Grid Services. 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 noticao 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 Globus, 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 dene Grid Services, OGSI especica o comportamento de Grid Services, Web Services so estendidos para se tornar Grid Services e Globus 3 implementa a especicao OGSI. Alm disso, Globus prov servios bsicos necessrios para a construo de servios de mais alto nvel (e.g. servios de autenticao via GSI).
VERSAO

1.0

PGINA 292

G UIA DE C LUSTER

13.2.7 - PADRONIZAO

WSRF /Globus

4.x

Uma vez que toda a base de Grid Services surgiu das tecnologias para Web Services, alguns aspectos da especicao OGSI precisavam ser renados devido a evoluo da arquitetura Web Services. O principal ponto de crtica foram os mecanismos de endereamento para os servios (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 modicadas para acompanhar a evoluo da tecnologia Web Service, melhorando assim a especicao OGSI . Assim, WSRF (Web Service Resource Framework) basicamente o resultado do renamento de OGSI no intuito de aproveitar a existncia dos novos padres que surgiram para para Web Services (e.g. WS-Addressing, WS-Notication) e assimilar a demanda da comunidade Web Services. O primeiro efeito do refatoramento foi a diviso de OGSI em vrias especicaes separadas, porm agrupadas em uma famlia. A idia reduzir a complexidade de uma especicao longa, que diculta a adoo incremental de funcionalidades. Outra medida importante foi a recuperao da compatibilidade com as ferramentas existentes para XML e Web Services, pois OGSI usa GWSDL, a qual prov acrscimos WSDL 1.1 que estaro disponveis na WSDL 1.2/2.0. Ao contrrio de OGSI, ao invs de estender a denio 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 Services 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 modica esse modelo para criar uma distino explcita entre servio e entidades que mantm estado e so manipuladas atravs do servio. Esta composio denominada WS-Resource pelo padro WSRF, que introduz a idia de recursos que mantm estados e podem ser acessados atravs de
VERSAO

1.0

PGINA 293

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 incremental. A primeira, a introduo do conceito de WS-Resource. Em seguida a diviso de funcionalidades em vrias especicaes melhorando a compatibilidade com ferramentas usadas para Web Service. Finalmente, uma melhoria nos mecanismos de noticao. 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 WSGRAM ,

o qual segue as especicaes denidas 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 deniremos quais so os tipos de aplicaes paralelas mais adequadas para executar em um Grid Computacional. 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, imagem do sistema e escala.
VERSAO

1.0

PGINA 294

G UIA DE C LUSTER

13.3.1 - P LATAFORMAS PARA P ROCESSAMENTO PARALELO

Conectividade diz respeito aos canais de comunicao que interligam os processadores que compem a plataforma de execuo. Atributos que denem a conectividade de uma plataforma so a topologia, largura de banda, latncia 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 processadores 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 paralela em uma plataforma adequada s caractersticas da aplicao. Por exemplo, considere conectividade, um aspecto em que plataformas diferem consideravelmente. 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 processadores e executam uma nica cpia do sistema operacional para todos os processadores. Portanto, eles apresentam uma imagem nica do sistema e excelente conectividade. Todavia, multiprocessadores apresentam limitaes em escalabilidade, raramente ultrapassando algumas dezenas de processadores. Multiprocessadores so relativamente comuns no mercado e vo desde mquinas biprocessadas 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
VERSAO

1.0

PGINA 295

G UIA DE C LUSTER

13.3.1 - P LATAFORMAS PARA P ROCESSAMENTO PARALELO

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 usurio. 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 sucientes para executar uma aplicao assim que ela submetida. Neste caso, a aplicao espera em uma la at que os recursos que solicitou estejam disponveis. A Figura 13.8 exemplica a arquitetura de um MPP.

Figura 13.8: Arquitetura de um MPP

VERSAO

1.0

PGINA 296

G UIA DE C LUSTER

13.3.1 - P LATAFORMAS PARA P ROCESSAMENTO PARALELO

N O Ws (ou redes de estaes de trabalho) so simplesmente um conjunto de estaes de trabalho ou PCs, ligados por uma rede local. N O Ws so arquiteturalmente 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 partio 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 esquematicamente 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 processadores, 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 instalado, sistemas de arquivo montados e perifricos instalados. Alm disso, os componentes de um Grid tipicamente estar sobre controle de diferentes entidades e, portanto, em domnios administrativos diversos. Conseqentemente, um dado usurio pode ter acesso e permisses bastante diversas nos diferentes componentes 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

VERSAO

1.0

PGINA 297

G UIA DE C LUSTER

13.3.1 - P LATAFORMAS PARA P ROCESSAMENTO PARALELO

exemplo). importante salientar que uma aplicao que executa sobre o Grid deve estar preparada para lidar com todo este dinamismo e variabilidade da plataforma de execuo, adaptando-se ao cenrio que se apresenta com o intuito de obter a melhor performance possvel no momento. A Figura 13.10 exemplica um possvel Grid, composto por um MPP e computadores de vrios tipos conectados 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 aplicaes 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 exemplo, alguns MPPs oferecem suporte de hardware a memria compartilhada, atravs de uma tecnologia denominada DSM (Distributed Shared Memory), o que
VERSAO

1.0

PGINA 298

G UIA DE C LUSTER

13.3.1 - P LATAFORMAS PARA P ROCESSAMENTO PARALELO

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 sobre 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 radicalmente 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 norteamericanos 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 vericar 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 ecientemente 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 aplicaes fracamente acopladas, enquanto o TeraGrid pode propiciar condies para execuo eciente de aplicaes fortemente acopladas).

VERSAO

1.0

PGINA 299

G UIA DE C LUSTER

13.3.2 - E XECUO R EMOTA

Conectividade Heterogeneidade Compartilhado Imagem Escala

SMP excelente nula no nica 10

MPP muito boa baixa no comum 1.000

NOW boa mdia sim comum 1.000

Grid regular/ruim alta sim mltipla 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 aplicaes paralelas. Alm disso, apresentamos o que diferencia os Grids de outras plataformas mais tradicionais para processamento de alto desempenho. Vale ressaltar que o componente fundamental dos Grids para Alto Desempenho o servio de execuo remota. Este servio responsvel por qualicar o grid como plataforma 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 aplicaes em qualquer outro servio mais especco. 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 exibilidade adquirida atravs do fornecimento de um servio de execuo genrico, que pode ser convertido em outros servios mais especcos, aumenta a complexidade da infraestrutura. Portanto, novas questes devem ser consideradas para que seja possvel fornecer um servio de execuo remota eciente. Por exemplo, quais servios de execuo remota, disponveis no Grid, devem ser usados, de forma a obter uma execuo eciente da aplicao de processamento de imagens? Como proteger o servio de aplicaes maliciosas? Discutiremos vrias dessas questes nas prximas sees.

13.3.3 Escalonamento
Um dos aspectos mais importantes para o desenvolvimento dos Grids a implementao de estratgias de alocao de recursos para as vrias aplicaes que usam a infraestrutura. Sendo assim, tanto possvel pensar em escalonamento
VERSAO

1.0

PGINA 300

G UIA DE C LUSTER

13.3.3 - E SCALONAMENTO

de aplicaes, bem como escalonamento de recursos. Em geral, os objetivos dessas 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 recurso distintos, algum tem que (i) escolher quais recursos sero utilizados na execuo da aplicao, (ii) estabelecer quais tarefas cada um destes recursos realizar, e (iii) submeter solicitaes aos escalonadores de recurso apropriados para que estas tarefas sejam executadas. Esta o papel do escalonador de aplicao. Escalonadores 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 camadas, com parte da responsabilidade pelo escalonamento sendo transferida dos
VERSAO

1.0

PGINA 301

G UIA DE C LUSTER

13.3.3 - E SCALONAMENTO

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 utilizados e quais tarefas cada um destes recursos realizar) so normalmente baseadas 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]. Portanto, 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 saber 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 informao, foram desenvolvidos sistemas que monitoram e prevem o comportamento futuro de diversos tipos de recursos [262, 392]. Este esquema de obteno de informao baseado em monitorao tem se mostrado ecaz 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].
VERSAO

1.0

PGINA 302

G UIA DE C LUSTER

13.3.3 - E SCALONAMENTO

Previso de Desempenho

Apesar de serem teis e ajudarem no desenvolvimento de heursticas de escalonamento ecientes, as infraestruturas de monitorao e previso de desempenho tm um desao 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 m de fornecer informaes 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 foram desenvolvidos. Como consequncia vrias heursticas foram desenvolvidas dependendo das informaes fornecidas por estas infraestruturas de monitorao [111, 89]. Uma servio utilizado por vrias heursticas de escalonamento o Network Weather Service (NWS) [392]. O NWS um sistema que monitora e dinamicamente prov estimativas de desempenho de recursos computacionais (ex.: processadores 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 informao para melhorar a ecincia 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 desempenho 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 informaes 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 informaes sobre os recursos do Grid, o Global Grid Frum [196] mantm grupos de trabalho discutindo sobe questes relacionadas denio 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],
VERSAO

1.0

PGINA 303

G UIA DE C LUSTER

13.3.3 - E SCALONAMENTO

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 introduzir 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 desempenho extremamente til, bem como estratgias ecientes de escalonamento 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 nitas da equao de Poisson e portanto aplicvel a problemas que envolvem uxo 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 bidimensional 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
VERSAO

1.0

PGINA 304

G UIA DE C LUSTER

13.3.3 - E SCALONAMENTO

trabalho balanceia a carga entre os processadores, garantindo bom desempenho. Em um Grid, entretanto, processadores e canais de comunicao so heterogneos. Alm disso, outras aplicaes esto concorrendo pelos mesmos recursos (processadores e canais de comunicao) enquanto Jacobi executa. Conseqentemente, 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 comunicao 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 simplicado pela deciso de utilizar um particionamento 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 Ti o tempo para o processador i executar uma iterao. Ai a rea da submatriz alocada ao processador i.
VERSAO

(13.1)

1.0

PGINA 305

G UIA DE C LUSTER

13.3.3 - E SCALONAMENTO

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 especca da aplicao (que cresce quadraticamente com a diferena 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 processadores. 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 . Assuma 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 processadores. 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 possibilidade 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 Jacobi 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 executam por mais tempo (horas, digamos), seria necessrio prever a disponibilidade 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 esVERSAO

1.0

PGINA 306

G UIA DE C LUSTER

13.3.3 - E SCALONAMENTO

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 escalonadores 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 canais de comunicao, que crescem quadraticamente com o nmero de mquinas do Grid. Em Francis, et al. [189] apresentada uma discusso sobre a diculdade e se construir um sistema escalvel para monitoramento de canais de comunicao.

Aplicaes Bag-of-Tasks

Apesar de ser possvel efetuar escalonamentos ecientes usando informao sobre o desempenho dos recursos, muitas aplicaes podem ser escalonadas de forma eciente sem o uso dessa informao. Isso possvel devido a algumas caractersticas da aplicao. Em particular, aplicaes Bag-of-Tasks so aplicaes 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 caVERSAO

1.0

PGINA 307

G UIA DE C LUSTER

13.3.3 - E SCALONAMENTO

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 la 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 la 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 informaes 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 tarefas (quanto maior, mais heterogneo). Note que WQR foi executado trs vezes, com replicao mxima de 2, 3 e 4 processadores. Observe tambm que Sufferage 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 tradicionais. A Figura 10 mostra o consumo adicional de CPU em funo da heterogeneidade das tarefas. Em situaes que a heterogeneidade de tarefas pequena, este consumo no signicativo, 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

VERSAO

1.0

PGINA 308

G UIA DE C LUSTER

13.3.3 - E SCALONAMENTO

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 desperdcio de CPU ca sempre abaixo de 40%.

Aplicaes que Processam Grandes Quantidades de Dados

Apesar de WQR ser uma heurstica eciente, 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], renderizao de imagens [139, 254, 322, 207]. Sendo assim, uma heurstica de escalonamento que melhore o desempenho dessas aplicaes bastante relevante. Felizmente, algumas aplicaes apresentam caractersticas que podem ser exploradas por heursticas de escalonamento para obter escalonamentos ecientes.
VERSAO

1.0

PGINA 309

G UIA DE C LUSTER

13.3.3 - E SCALONAMENTO

Figura 13.15: Desperdcio de ciclos com a replicao

Pensando nisso, foi desenvolvida a heurstica Storage Afnity[321], que explora padres de reutilizao de dados e aplica replicao de forma semelhante a WQR. Os padres de reutilizao foram classicados em dois tipos bsicos, inter-job e inter-task. O padro inter-job determina que h reutilizao de dados entre execues sucessivas das aplicaes. Vale salientar que isso bastante comum em aplicaes do tipo Parameter Sweep [113]. Outra situao de reutilizao capturada pela denio 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 melhorar o desempenho das aplicaes. Assim, Storage Afnity efetua o escalonamento baseado anidade que as tarefas tm com os sites que formam o Grid. O valor da anidade 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 anidade de uma tarefa com um site o nmero de bytes pertencentes entrada da tarefa,
VERSAO

1.0

PGINA 310

G UIA DE C LUSTER

13.3.3 - E SCALONAMENTO

Figura 13.16: Sumrio do desempenho de Storage Afnity comparado com outras heursticas

que j esto armazenados no site. Note que Storage Afnity utiliza to somente as informaes sobre o tamanho e a localizao dos arquivos de entrada. importante dizer que tais informaes podem estar disponveis no instante do escalonamento sem diculdade 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 requisies sobre quais elementos de dados eles armazenam e qual o tamanho de cada elemento de dado, uma implementao alternativa da heurstica Storage Afnity 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 Afnity tambm trata a diculdade na obteno de informaes dinmicas sobre o Grid, bem como informaes sobre o tempo de execuo das tarefas da aplicao. Para resolver este problema, Storage Afnity efetua replicao de tarefas. Storage Afnity executa em duas fases. Na primeira fase, cada tarefa associada a um processador. A ordem de escalonamento determinada atravs do clculo do valor da anidade das tarefas. Aps determinar as anidades, a tarefa que apresentar o maior valor escalonada em um processador do site com o qual a tarefa apresentou maior anidade. A segunda fase consiste da replicao de tarefas.
VERSAO

1.0

PGINA 311

G UIA DE C LUSTER

13.3.3 - E SCALONAMENTO

Figura 13.17: Sumrio do desperdcio de recursos por Storage Afnity comparado com outras heursticas

Esta fase inicia quando no h mais tarefas aguardando para executar e pelo menos 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 vericados na escolha de qual tarefa deve ser replicada: i) a tarefa deve estar executando e ter um valor de anidade 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 corrente da tarefa deve ser o menor entre as tarefas que atendem o critrio (i); e iii) a tarefa deve apresentar o maior valor de anidade entre as tarefas que atendem o critrio (ii). Quando uma tarefa completa sua execuo as outras rplicas da tarefa so interrompidas. O algoritmo naliza 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 heursticas: WQR, XSufferage e Storage Afnity. 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 Afnity consegue melhor desemVERSAO

1.0

PGINA 312

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 desperdcio de recurso entre Storage Afnity 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 bastante o desperdcio de largura de banda da rede. Para Storage Afnity 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 lidarmos com o sistema. So tais abstraes que nos permitem expressar o queremos fazer. Elas tambm nos permitem nomear os dados persistentes que temos armazenados 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 congurao dos processadores que compem a plataforma para compartilhar 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
VERSAO

1.0

PGINA 313

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). Entretanto, 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 eciente de usar o Grid.

13.3.5 Segurana
Um dos desaos 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 conveis. Portanto, segurana um tpico que deve se considerado para o desenvolvimento 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 aplicao iniciada por um usurio do domnio X no contm cdigo malicioso que podem prejudicar o funcionamento dos recursos utilizados?
VERSAO

1.0

PGINA 314

G UIA DE C LUSTER

13.3.5 - S EGURANA

Uma primeira, e bvia, medida implementar mecanismos de autenticao e autorizao para permitir que apenas usurios do domnio X , que sejam autenticados 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 mquina 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 exibilidade no gerenciamento de sistemas FreeBSD. A idia que o esquema de autorizao clssico do Unix pouco sosticado para situaes onde h uma demanda por uma granularidade mais na nos nveis de permisses sobre o recursos. Essa estratgia funciona atravs do connamento 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 connado utilizando a chamada de sistema chroot(). Esta chamada foi modicada 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 connado 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, enquanto algum processo remoto executa em uma partio isolada do resto do sistema. 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
VERSAO

1.0

PGINA 315

G UIA DE C LUSTER

13.3.5 - S EGURANA

estrangeiro. Sendo assim, outras alternativas fornecem mecanismos de deteco de ociosidade que prepara o ambiente para receber processos estrangeiros e executlos 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 danicao, 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 modicado 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 mquina 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 denido 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 requisitado por um cliente. Por exemplo, suponha um servio que fornece renderizao de imagens. O servio supostamente estaria disponvel para responder a requisies 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 exterVERSAO

1.0

PGINA 316

G UIA DE C LUSTER

13.3.5 - S EGURANA

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 conveis [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 infraestruturas guravam em um ranking. Assim, atravs de uma modicao no servio de execuo, se tornava possvel enganar o sistema retornando um resultado invlido 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 nais 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 contornar a limitao do majority voting usar a poltica denominada spot-checking [324]. Nesse esquema, os voluntrios so vericados de forma aleatria atravs da solicitao de execuo de um benchmark. A inteno vericar se possvel conar 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 retornados por este voluntrio so descartados e colocados na lista de trabalho pendente.

VERSAO

1.0

PGINA 317

G UIA DE C LUSTER

13.4 - E STUDOS DE C ASO

Uma vez que spot-checking baseada na vericao aleatria da conabilidade dos voluntrios. Assim, ao detectar que um voluntrio no convel, todos os resultados anteriores deste voluntrio so descartados e o trabalho reenviado a outros voluntrios. Nesse estratgia, h uma menor repetio de trabalho, quando comparamos estratgia majority voting. Existem duas variaes da estratgia spot-checking: i) spot-checking with blacklist; ii) spot-checking without blacklist. 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 maliciosos de forma eciente. Por exemplo, usar o IP para identicar 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 denio de credibilidade [324]. A idia marcar vrios objetos do sistema com um valor que descreve sua credibilidade. Ento, possvel que voluntrios, resultados e grupos 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 vericada. Note que uma combinao de majority voting 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 infraestruturas 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.
VERSAO

1.0

PGINA 318

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 denidas 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 identicao 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 autenticao so agravados, pois queremos servios que possam efetuar aes automaticamente, porm essas aes exigem autenticao (e.g. submeter uma tarefa para execuo em um site remoto, solicitar o armazenamento ou acesso a um determinado 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 relacionadas a delegao de credencial esto envolvidas no processo de autenticao. (Globus Security Infrastructure) o servio Globus que ataca estes problemas. GSI viabiliza o login nico no Grid. GSI utiliza criptograa de chave pblica, certicados X.509 e comunicao SSL (Secure Sockets Layer) para estabelecer a identidade Globus do usurio. Por exemplo, C=US,O=University
GSI

of California San Diego, OU=Grid Computing Lab, CN=Walfredo Cirne era uma identidade em Gusto (o primeiro Grid montado com Globus). Depois do usurio ter se identicado 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
VERSAO

1.0

PGINA 319

G UIA DE C LUSTER

13.4.1 - G LOBUS

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 especicao 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 especicaes que denem formatos para descrio de polticas de segurana, formatos para delegao de credencial e autenticao e estabelecimento de comunicao segura, puderam ser aproveitados 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. (Globus Resource Allocation Manager) o servio da arquitetura Globus que fornece uma interface uniforme para submisso e controle de tarefas [133], escondendo a multiplicidade de escalonadores de recursos dos demais servios de Grid
GRAM

(do escalonador de aplicaes, por exemplo). Alm disso, GRAM prov informaes 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 identicao dos trs compoVERSAO

1.0

PGINA 320

G UIA DE C LUSTER

13.4.1 - G LOBUS

Figura 13.18: Arquitetura do GRAM [133]

nentes do GRAM (Gatekeeper, Job Manager e GRAM Reporter), bem como componentes 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 Resource Manager, na Figura 13.18) usado para controlar a mquina. Isto possvel porque as requisies enviadas ao GRAM so sempre escritas em RSL (Resource Specication 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 podem usar os servios de outros escalonadores de aplicao. O escalonador que recebe a solicitao do cliente lida com a especicao em mais alto nvel. Ele rena tal especicao e, para implement-la, submete novas solicitaes a escalonadores 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. capaz de expressar tanto solicitao de alto nvel (como a que o usurio envia a seu escalonador de aplicaes), como tambm solicitaes concretas (que
RSL
VERSAO

1.0

PGINA 321

G UIA DE C LUSTER

13.4.1 - G LOBUS

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 renar 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 acopladas o co-alocador (Co-allocator). O co-alocador um escalonador de aplicao especializado em garantir que tarefas localizadas em mquinas distintas executem 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 escalonadores 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 simulao interativa envolvendo 100.000 entidades para um escalonador de aplicao especializado em simulao interativa distribuda. Tal escalonador converte a so-

VERSAO

1.0

PGINA 322

G UIA DE C LUSTER

13.4.1 - G LOBUS

Figura 13.20: Exemplo do uso de escalonadores no Globus [133]

licitao original em outra mais especica, 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 escalonador 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 renada para o co-alocador. O co-alocador garante que as tarefas submetidas aos distintos MPPs comecem a executar simultaneamente. Note tambm que outros escalonadores de aplicaes podem participar do sistema. A Figura 13.20, por exemplo, exemplica 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 conito entre generalidade e performance. Caso utilizemos um mecanismo de comunicao genrico (e.g. TCP) que viabilize a comunicao m-a-m entre quaisquer duas tarefas no Grid, perdemos performance em casos especiais (e.g.
VERSAO

1.0

PGINA 323

G UIA DE C LUSTER

13.4.1 - G LOBUS

se ambas tarefas rodam em uma mquina de memria compartilhada, elas poderiam 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 tecnologias 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 estejam em um MPP, Nexus utilizar o switch de alta velocidade para comunicao. Caso as tarefas estejam em mquinas geogracamente distantes, Nexus utilizar TCP/IP. Nexus fornece uma interface de relativo baixo nvel: invocao remota de procedimento, mas sem retorno de resultado. Portanto, programar diretamente em Nexus no das tarefas mais agradveis. Entretanto, a idia da equipe Globus que Nexus seja usado por desenvolvedores de ferramentas e mecanismos de comunicao, 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 servio GASS implementa as otimizaes tpicas de acesso remoto como caching e pre-fetching.
VERSAO

1.0

PGINA 324

G UIA DE C LUSTER

13.4.1 - G LOBUS

Apesar de ser um bom servio, o GASS encontrou problemas de implantao. A diculdade 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 motivou 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 anamento de performance) Instrumentao embutida

Uma vez que GridFTP uma extenso do FTP, o problema de interoperabilidade ca resolvido, pois FTP amplamente suportado pelos servidores de dados. Obviamente, se as extenses GridFTP no estiverem implementadas em um dado servidor, os benefcios adicionais do protocolo no estaro disponvel. Mas o cliente 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 oferecidos so razoavelmente independentes, possibilitando que se utilize apenas parte dos servios Globus em uma dada soluo. Essa possibilidade do uso parcial de Globus ajuda sobremaneira na adaptao de aplicaes paralelas existentes 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 exemplicado pelo Legion [204]. Legion fornece um modelo orientado a objetos poderoso e exvel. Entretanto, o
VERSAO

1.0

PGINA 325

G UIA DE C LUSTER

13.4.1 - G LOBUS

usurio tem que utilizar a soluo Legion de forma integral, sem estgios intermedirios. Esta diferena de abordagem talvez tenha contribudo para prevalncia 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 completa (plug-and-play) para construo de Grids. Globus certamente fornece servios teis para Computao em Grids. Mas, desenvolvedores, administradores e usurios precisam despender certo esforo para nalizar 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 modicaram em busca da implementaes de padres que promovem maior interoperabilidade. A arquitetura do Globus Toolkit 3 ilustrada pela Figura 13.21. Essa verso uma implementao da especicao OGSI (Open Grid Services Infrastructure) [368], os servios implementados na camada GT3 Core Services representam os servios especicados pela OGSI. O objetivo especicar mecanismos para criao, gerenciamento e troca de dados entre Grid Services. Como discutimos nas Sees 13.2.7 e 13.2.7, h uma tendncia forte de convergncia entre as tecnologias de Grids Computacionais e Web Services. Isso ca
VERSAO

1.0

PGINA 326

G UIA DE C LUSTER

13.4.2 - M Y G RID

Figura 13.21: Arquitetura do Globus [345]

claro com a introduo da especicao 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 Computacionais, poucos usurios executavam suas aplicaes paralelas sobre essa infraestrutura. Assim, foi concebido projeto MyGrid, com o intuito de alterar esta situao. 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) resolvem vrios problemas importantes, tais como minerao de dados, processamento genmico, pesquisa massiva (como quebra de chaves criptogrcas), varredura de parmetros, simulaes Monte Carlo (muito utilizado, por exemplo, pela indstria farmacutica [215]), computao de fractais (como Mandelbrot), e manipulao de imagem (como tomograa). 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 possvel de uma soluo pronta (plug-and-play). Por completo denotamos a necessidade de cobrir todo o ciclo de uso de um sistema computacional, do desenvolvimento execuo, passando por instalao e atualizao e incluindo tambm
VERSAO

1.0

PGINA 327

G UIA DE C LUSTER

13.4.2 - M Y G RID

a manipulao de arquivos. Por seguro expressamos a necessidade de no introduzir 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 vezes 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 familiar. 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 mantermos 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 quaisquer recursos que ele tenha acesso . Este no um objetivo trivial porque ele implica 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 nossas hipteses. Em particular, no podemos assumir que tal recurso tenha software MyGrid instalado. MyGrid dene 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
VERSAO

1.0

PGINA 328

G UIA DE C LUSTER

13.4.2 - M Y G RID

Servios Execuo remota Transferncia de Arquivo (Mquina Base Grid Machine) Transferncia de Arquivo (Grid Machine 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. Alternativamente, 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 mecanismo 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 nalmente submete e monitora a execuo da tarefa. O
VERSAO

1.0

PGINA 329

G UIA DE C LUSTER

13.4.2 - M Y G RID

MyGrid possui atualmente duas heurstica de escalonamento: Workqueue with Replication (WQR) [299] e Storage Afnity [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 denido para aplicaes cpu-intensive, enquanto Storage Afnity 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 simplica a denio da Grid Machine Interface. Caso o algoritmo de escalonamento do MyGrid necessitasse de informaes 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] dene uma interface de abstrao para os recursos, que contempla mtodos de fornecimento de informao sobre o recurso. Certamente, a informao obtida por esses mtodos valiosa para o escalonamento eciente 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 tarefas so compostas por trs partes ou sub-tarefas: init, remote e nal. As sub-tarefas so executadas seqencialmente (init remote f inal). As sub-tarefas init e nal so usadas para efetuar as transferncias de arquivo de entrada e sada da tarefa respectivamente. Sendo assim, tanto a sub-tarefa inicial quando a nal 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 propriamente dita da tarefa. Para denir as sub-tarefas inicial e nal, o usurio tem disponvel algumas abstraes 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 armazenamento persistente execuo da tarefa. Ou seja, til usar storage para distribuio de arquivos que provavelmente sero reutilizados no Grid (ex.: executveis 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

VERSAO

1.0

PGINA 330

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 possibilitar o armazenamento de dados temporrios e resultados de tarefas. Tambm no sentido de simplicar a escrita das sub-tarefas, as variveis de ambiente $ STO RAGE , $ PLAYPEN , $ PROC e $ TASK so automaticamente denidas 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 escolhida para executar a tarefa e um identicador da tarefa.

13.4.3 OurGrid
Ao contrrio do Globus, a soluo OurGrid tem um escopo diferente, porm complementar. O objetivo prover uma soluo efetiva para a execuo de aplicaes Bag-of-Tasks em Grids Computacionais. Sendo assim, as decises de projeto esto 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 soluo, apesar de simples, eciente 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 operacional 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
VERSAO

1.0

PGINA 331

G UIA DE C LUSTER

13.4.3 - O UR G RID

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 certicados 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 requisitando 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 broker, quanto os peers da comunidade possuem uma lista de certicados que so usadas para validar a tentativa de aceso. Isso impede que usurios no autorizados pelo peer, obtenham acesso aos servios 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 certicados, a comunicao entre o MyGrid Broker, o peer e as Grid Machines ser segura, evitando que os dados sejam interceptados e manipulados durante a comunicao. A segurana 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 conjunto 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 necessrio, mnimo de memria, arquitetura do processador). Em seguida, o usurio o submete sua aplicao para execuo no Grid atravs do MyGrid Broker. O componente 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 aplicao submetida pelo usurio. Esses provedores podem responder com recursos
VERSAO

1.0

PGINA 332

G UIA DE C LUSTER

13.4.3 - O UR G RID

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 Broker, ou seja, isso no signica 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 especicado em seus requisitos que necessita de uma G U M (Grid Machine), 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 especicado pela aplicao. Portanto, apesar de no ter uma arquitetura que prov comunicao entre as tarefas que esto sendo executadas nas GuMs, a soluo OurGrid prov meios de agregar ao Grid GuMs que permitem a execuo de aplicaes fortemente acopladas.
VERSAO

1.0

PGINA 333

G UIA DE C LUSTER

13.4.3 - O UR G RID

Transferncia de Dados

A soluo OurGrid para transferncia de dados baseada no tratamento de arquivos. 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 certicados.

Avaliao do OurGrid

A caracterstica mais importante do OurGrid conseguir prover uma soluo til e eciente 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-ofTasks). importante notar que o objetivo do OurGrid contrasta com o objetivo do Globus, 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 Globus e no-Globus. Por outro lado, Globus complementa o OurGrid ao fornecer a infraestrutura de servios para execuo de aplicaes em larga escala.
VERSAO

1.0

PGINA 334

G UIA DE C LUSTER

13.4.4 - C ONDOR

OurGrid persegue um objetivo diferente do que seria prover uma soluo genrica 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 funcionalidades, que aumentem o escopo da soluo. Ao contrrio, a idia gradativamente permitir que mais aplicaes possam utilizar a soluo. Por exemplo, suporte a workow, 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 melhorias 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 denido e menos genrico que outras solues para computao de alto desempenho em Grids Computacionais. Condor objetiva fornecer grande quantidade 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 performance) [85, 165, 191, 258]. Entenda-se disto que Condor visa fornecer desempenho 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 Workstations). 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 necessidades de cada tarefa e nas restries de uso de cada mquina. As necessidades de uma tarefa so especicadas pelo usurio quando de sua submisso. Por exemplo, 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 especicadas por seu dono quando da incluso da mquina no Pool. Por
VERSAO

1.0

PGINA 335

G UIA DE C LUSTER

13.4.4 - C ONDOR

exemplo, o dono pode preferir que sua mquina execute as aplicaes de Joo, seguido 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 tambm que sua mquina s usada quando estiver ociosa e que, quando ele voltar a utilizar a mquina, qualquer aplicao Condor em execuo seja suspensa imediatamente. 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 similar, 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 atributos da mquina, o Matchmaker notica 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 especica 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.

VERSAO

1.0

PGINA 336

G UIA DE C LUSTER

13.5 - I NTEGRAO DE CLUSTERS EM GRIDS

Condor foi posteriormente estendido para execuo em Grids [165, 191]. interessante 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 bastante elegante do ponto de vista de sistemas distribudos pois no acrescenta nenhuma centralizao a arquitetura Condor original. A base para criao de um Flock um acordo de cooperao (de troca de recursos) entre dois Condors Pools. 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 Condors 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 rmam um acordo de cooperao instalam cada qual um Gateway. 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 repassa 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. Devido necessidade de suportar mais heterogeneidade, Condor-G usa uma arquitetura mais centralizada que o Flock of Condors. O Condor-G Scheduler controla a execuo da aplicao, submetendo tarefas tanto a Condor Pools quanto a recursos 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, devido enorme capacidade computacional que so capazes de fornecer. Porm, a utilizao dos clusters no uma tarefa trivial, devido a caractersticas inerentes
VERSAO

1.0

PGINA 337

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 la 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 especicar uma quantidade de mquinas e um tempo de utilizao das mesmas, ele precisa conhecer a sua aplicao e a capacidade das mquinas, a m 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 desempenho). 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 sucientes para atender as requisies maiores, adiantando as primeiras). Em grids, o problema da diculdade de estabelecer o tempo de execuo aumenta, 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 especca do gerenciador utilizado no determinado cluster (Figura 13.24).

VERSAO

1.0

PGINA 338

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 especcos o GRAM (Grid Resource Allocation and Management) do Globus. Ele recebe as requisies (RSL Resource Specication Language) e capaz de convert-las para gerenciadores especcos. 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 recursos especco, 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 especicar 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 transparente, apresentada originalmente em [288]. A tcnica pode ser utilizada quando a aplicao a ser executada no grid composta 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 cam disponveis para a execuVERSAO

1.0

PGINA 339

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 cancelamento 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 retomada 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 melhor 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 incentivar 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 comunidade OurGrid. Formas como tal heurstica pode ser implementada na prtica, avaliao da tcnica 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 Computacionais, desde a apresentao de um conceito do que classica 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 pesquisa, porm seus benefcios vo alm de uma simples plataforma para execuo de aplicaes em larga escala. A idia facilitar a colaborao de grupos de
VERSAO

1.0

PGINA 340

G UIA DE C LUSTER

13.6 - T ENDNCIAS EM G RIDS C OMPUTACIONAIS

pesquisa distribudos geogracamente. Mostramos ento que os Grids Computacionais como uma tecnologia que nasceu 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 denio 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 desenvolvimento dos Grids, a tendncia que Grids se tornem uma infraestrutura global de computao orientada a servios, atendendo tanto a comunidade de computao cientca de alto desempenho, quanto a comunidade de computao comercial. Finalmente, a discusso sobre os padres emergentes para o desenvolvimento de infraestruturas de Grids Computacionais, mostra que os esforos tm amadurecido, 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.

VERSAO

1.0

PGINA 341

Captulo 14 Virtualizao de recursos


Virtualizao o modo de apresentao ou agrupamento de um subconjunto lgico de recursos computacionais de modo que possam ser alcanados resultados e benefcios como se o sistema estivesse executando sobre a congurao 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 geogrca ou pela congurao fsica de recursos. Uma tendncia nova na virtualizao o conceito de um motor de virtualizao" 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 utilizado 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 diferentes 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.
VERSAO

1.0

PGINA 342

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 operacional 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 modicaes 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 modicaes funcione isoladamente no hardware, mas o Sistema Operacional 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 modicaes no kernel do Sistema Operacional hospede. As chamadas de sistema ao hypervisor conhecida 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 ambientes dos Sistemas Operacionais hospedes so os mesmos que o do Sistema 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 server 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 operacionais.

VERSAO

1.0

PGINA 343

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 necessrios para execuo. Este ambiente virtual age como uma camada entre a aplicao e o sistema operacional e elimina conitos entre a aplicao e as aplicaes do sistema operacional. (Softricity, Thinstall, Appstream, Ardence, Trigence, Neoware)

14.1.2 Virtualizao nativa

Virtualizao nativa, tambm conhecida como virtualizao acelerada ou hbrida, 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 virtualizao 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 despesas de manuteno da paravirtualizao no que tange a quantidade de alteraes necessrias no sistema operacional convidado, e tambm obtm tambm considervel 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 ecientemente em uma VMM. provvel que, com as novas tecnologias de virtualizao nativa de X86 e X86_64 da Intel (Vander Pool) e da AMD (Pacica), 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.
VERSAO

1.0

PGINA 344

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 abstrao 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 modicaes do sistema operacional hospede. O Xen mantido pela Universidade de Cambridge e conta com apoio de empresas 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 stio 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 geogrca. 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 Operacional 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 mesmos dados estar localizado em outro continente sem que ao menos o usurio que os acessa perceba a mudana geogrca do Sistema Operacional. Aliando-se sistemas de balanceamento de carga, alta disponibilidade, consolidao de recursos computacionais e sistemas de arquivos em cluster, esta tarefa
VERSAO

1.0

PGINA 345

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 privilegiado ao hypervisor, permitindo a ela as operaes necessrias que as demais mquinas virtuais no podem executar. A mquina virtual Dom0 ento responsvel pelo gerenciamento de toda a estrutura de gerenciamento de virtualizao fazendo uso de aplicaes que tem acesso ao hypervisor. nesta mquina virtual 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 nal, 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:


VERSAO

1.0

PGINA 346

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 administradores iniciem e executem dinamicamente uma instncia do sistema operacional sem afetar o servio.

14.2.2 Sistema Operacional nativo versus virtualizao com Xen


Algumas justicativas 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 losco - a convico de que os data centers esto abarrotados de servidores subutilizados. Ela parece solucionar o problema criado pelo paradigma predominante do um servidor para um aplicativo que resulta do super-provisionamento visando mxima performance. As taxas de utilizao de servidores podem oscilar entre 5% e 15%. Por m, a promessa de servidores baseados em commodities resultou em data centers excessivamente caros de gerenciar, alimentar e refrigerar."

Esta armao faz cair por terra a tese de que necessrio o uso de um servidor 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 processadores (o Xen prov virtualizao dos processadores ou mesmo balanceamento de carga entre eles), reduzindo o espao fsico do Data Center e em contra partida reduzindo o consumo de energia eltrica para a alimentao dos servidores e conseguentemente para outros tens como condicionador de ar.
VERSAO

1.0

PGINA 347

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 congurado 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 aspectos de congurao 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 signica que deve haver um sistema de arquivos compartilhado (por exemplo, NFS) visvel aos hosts; O host de destino deve possuir memria livre o suciente 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 suspenso 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 utilizada 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
VERSAO

1.0

PGINA 348

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 mudanas feitas pelo Sistema Operacional, e decida como modicar 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 hypervisor. Finalmente, trabalhando cooperativamente com os Sistemas Operacionais hospedes, o hypervisor ganha a introspeco adicional do Sistema Operacional, e pode fazer com que ele que 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 eciente dos sistemas hospedados. A paravirtualizao disponibiliza benefcios signicantes em termos de drivers de dispositivos e interfaces. Essencialmente, drivers de dispositivos podem ser virtualizados utilizando o modelo de paravirtualizao, e assim, garantindo recursos de baixo nvel separados por domnios como memria, CPU e outros recursos. Alm disso, o prprio hypervisor protegido de eventuais erros e problemas com os drivers dos dispositivos e ainda pode-se empregar qualquer dispositivo disponvel no mercado no precisando assim um hardware ou driver especico. 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.

VERSAO

1.0

PGINA 349

Parte IV Apndices

VERSAO

1.0

PGINA 350

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 [Massachusetts] 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 modicao.

Introduo

As licenas da maioria dos softwares so elaboradas para suprimir sua liberdade de compartilh-los e modic-los. A Licena Pblica Geral do GNU, ao contrrio,
1

Disponvel em http://creativecommons.org/licenses/GPL/2.0/legalcode.pt.
1.0 PGINA 351

VERSAO

G UIA DE C LUSTER

CAPTULO A : L ICENA CC-GNU GPL

visa garantir sua liberdade de compartilhar e modicar softwares livres para assegurar 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 modic-lo ou usar partes dele em novos programas livres; nalmente, que voc tenha cincia de que pode fazer tudo isso. Para proteger seus direitos, necessitamos fazer restries que probem que algum negue esses direitos a voc ou que solicite que voc renuncie a eles. Essas restries se traduzem em determinadas responsabilidades que voc dever assumir, se for distribuir cpias do software ou modic-lo. Por exemplo, se voc distribuir cpias de algum desses programas, tanto gratuitamente 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 possam 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 autorais sobre o software e (2) concedendo a voc esta licena, que d permisso legal para copiar, distribuir e/ou modicar 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 software for modicado 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 liVERSAO

1.0

PGINA 352

G UIA DE C LUSTER

CAPTULO A : L ICENA CC-GNU GPL

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, simplesmente no deve ser licenciada. Os exatos termos e condies para cpia, distribuio e modicao seguem abaixo. TERMOS E CONDIES PARA CPIA, DISTRIBUIO E MODIFICAO.

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, referese a qualquer programa ou obra, e o termo obras baseadas no Programa signica tanto o Programa, como qualquer obra derivada nos termos da legislao de direitos autorais: isto , uma obra contendo o Programa ou uma parte dele, tanto de forma idntica como com modicaes, e/ou traduzida para outra linguagem. (Doravante, o termo modicao inclui tambm, sem reservas, a traduo). Cada licenciado, doravante, ser denominado voc. Outras atividades que no a cpia, distribuio e modicao, no so cobertas 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 Programa). Na verdade, isto depender daquilo que o Programa faz. 2. Voc poder fazer cpias idnticas do cdigo-fonte do Programa ao receblo 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 noticao sobre a exonerao de garantia; mantenha intactas as informaes, avisos ou noticaes referentes a esta Licena e ausncia de qualquer garantia; e fornea a quaisquer outros receptores 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.
VERSAO

1.0

PGINA 353

G UIA DE C LUSTER

CAPTULO A : L ICENA CC-GNU GPL

3. Voc poder modicar sua cpia ou cpias do Programa ou qualquer parte dele, formando, dessa forma, uma obra baseada no Programa, bem como copiar e distribuir essas modicaes 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 modicados contenham avisos, em destaque, informando que voc modicou os arquivos, bem como a data de qualquer modicao. 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 modicado 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, imprima ou exiba um aviso incluindo o aviso de direitos autorais (ou copyright) apropriado, alm de uma noticao de que no h garantia (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 imprimir normalmente avisos como esses, no obrigatrio que a sua obra baseada no Programa imprima um aviso). Essas exigncias se aplicam obra modicada como um todo. Se partes identicveis dessa obra no forem derivadas do Programa e puderem 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 separadas. 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 permisses para outros licenciados se estendero obra por completo e, conseqentemente, a toda e qualquer parte, independentemente de quem a escreveu. Portanto, esta clusula no tem a inteno de armar direitos ou contestar os seus direitos sobre uma obra escrita inteiramente por voc;
VERSAO

1.0

PGINA 354

G UIA DE C LUSTER

CAPTULO A : L ICENA CC-GNU GPL

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 volume 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 Clusulas 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 sicamente realizar a distribuio da fonte, uma cpia completa passvel de leitura pela mquina, do cdigo-fonte correspondente, 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 distribuir o cdigo-fonte correspondente. (Esta alternativa permitida somente 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 signica o formato preferencial da obra para que sejam feitas modicaes na mesma. Para uma obra executvel, o cdigo-fonte completo signica o cdigo-fonte inteiro de todos os mdulos que ela contiver, mais quaisquer arquivos de denio de interface associados, alm dos scripts usados para controlar a compilao e instalao do executvel. Entretanto, como uma exceo especial, o cdigo-fonte distribudo no precisa incluir nada que no seja normalmente 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.
VERSAO

1.0

PGINA 355

G UIA DE C LUSTER

CAPTULO A : L ICENA CC-GNU GPL

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, modicar, sublicenciar ou distribuir o Programa, exceto conforme expressamente estabelecido nesta Licena. Qualquer tentativa de, de outro modo, copiar, modicar, sublicenciar ou distribuir o Programa 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 modicar ou distribuir o Programa ou respectivas obras derivativas. Tais atos so proibidos por lei se voc no aceitar esta Licena. Conseqentemente, ao modicar 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 modicar 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 modicar o Programa, sujeito a estes termos e condies. 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 patente, ou por qualquer outro motivo (no restrito s questes de patentes), forem impostas a voc condies (tanto atravs de mandado judicial, contrato 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,
VERSAO

1.0

PGINA 356

G UIA DE C LUSTER

CAPTULO A : L ICENA CC-GNU GPL

ento, como conseqncia, voc no poder distribuir o Programa de nenhuma forma. Por exemplo, se uma licena sob uma patente no permite a redistribuio por parte de todos aqueles que tiverem recebido cpias, direta 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 executvel, sob qualquer circunstncia especca, 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 nalidade de induzir voc a infringir quaisquer patentes ou direitos de propriedade, nem de contestar a validade de quaisquer reivindicaes deste tipo; a nica nalidade desta clusula proteger a integridade 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, conando na aplicao consistente deste sistema; cabe ao autor/doador decidir 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 conseqncia do restante desta Licena. 9. Se a distribuio e/ou uso do Programa for restrito em determinados pases, tanto por patentes ou por interfaces protegidas por direito autoral, o titular original dos direitos autorais que colocar o Programa sob esta Licena poder acrescentar uma limitao geogrca 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 novas verses e/ou verses revisadas da Licena Pblica Geral. Essas novas verses sero semelhantes em esprito presente verso, mas podem diferenciar-se, porm, em detalhe, para tratar de novos problemas ou preocupaes. Cada verso recebe um nmero de verso distinto. Se o Programa especicar um nmero de verso desta Licena que se aplique a ela e a qualquer
VERSAO

1.0

PGINA 357

G UIA DE C LUSTER

CAPTULO A : L ICENA CC-GNU GPL

verso posterior, voc ter a opo de seguir os termos e condies tanto daquela verso como de qualquer verso posterior publicada pela Free Software Foundation. Se o Programa no especicar um nmero de verso desta Licena, voc poder escolher qualquer verso j publicada pela Free Software Foundation. 11. Se voc desejar incorporar partes do Programa em outros programas livres cujas condies de distribuio sejam diferentes, escreva ao autor solicitando a respectiva permisso. Para software cujos direitos autorais sejam da Free Software Foundation, escreva para ela; algumas vezes, abrimos excees para isso. Nossa deciso ser guiada pelos dois objetivos de preservar a condio livre de todos os derivados de nosso Software Livre e de promover o compartilhamento e reutilizao de software, de modo geral.

EXCLUSO DE GARANTIA 11. COMO O PROGRAMA LICENCIADO SEM CUSTO, NO H NENHUMA GARANTIA PARA O PROGRAMA, NO LIMITE PERMITIDO PELA LEI APLICVEL. EXCETO QUANDO DE OUTRA FORMA ESTABELECIDO POR ESCRITO, OS TITULARES DOS DIREITOS AUTORAIS E/OU OUTRAS PARTES, FORNECEM O PROGRAMA NO ESTADO EM QUE SE ENCONTRA, SEM NENHUMA GARANTIA DE QUALQUER TIPO, TANTO EXPRESSA COMO IMPLCITA, INCLUINDO, DENTRE OUTRAS, AS GARANTIAS IMPLCITAS DE COMERCIABILIDADE E ADEQUAO A UMA FINALIDADE ESPECFICA. O RISCO INTEGRAL 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 MODIFICAR E/OU REDISTRIBUIR O PROGRAMA, CONFORME PERMITIDO ACIMA, SER RESPONSVEL PARA COM VOC POR DANOS, INCLUINDO ENTRE OUTROS, QUAISQUER DANOS GERAIS, ESPECIAIS, FORTUITOS OU EMERGENTES, ADVINDOS DO USO OU IMPOSSIBILIDADE DE USO DO PROGRAMA (INCLUINDO, ENTRE OUTROS,
VERSAO

1.0

PGINA 358

G UIA DE C LUSTER

CAPTULO A : L ICENA CC-GNU GPL

PERDAS DE DADOS OU DADOS SENDO GERADOS DE FORMA IMPRECISA, PERDAS SOFRIDAS POR VOC OU TERCEIROS OU A IMPOSSIBILIDADE DO PROGRAMA DE OPERAR COM QUAISQUER OUTROS PROGRAMAS), MESMO QUE ESSE TITULAR, OU OUTRA PARTE, TENHA 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 Software Livre, o qual qualquer pessoa pode redistribuir e modicar sob os presentes termos. Para fazer isto, anexe as noticaes seguintes ao programa. mais seguro anexlas ao comeo de cada arquivo-fonte, de modo a transmitir do modo mais eciente a excluso de garantia; e cada arquivo deve ter ao menos a linha de direitos autorais reservados e uma indicao de onde a noticao 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 modiclo 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 Foundation, Inc., no endereo 59 Temple Street, Suite 330, Boston, MA 02111VERSAO

1.0

PGINA 359

G UIA DE C LUSTER

CAPTULO A : L ICENA CC-GNU GPL

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 noticao 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 Livre 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 apropriadas 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 autorais sobre o programa Gnomovision (que realiza passagens em compiladores), 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 programas proprietrios. Se seu programa uma biblioteca de sub-rotinas, voc poder considerar ser mais til permitir a ligao de aplicaes proprietrias sua biblioteca. Se isso o que voc deseja fazer, utilize a Licena Pblica Geral de Biblioteca do GNU, ao invs desta Licena.

VERSAO

1.0

PGINA 360

Apndice B Marcas Registradas


Foram utilizadas marcas registradas neste Documento com o propsito de identicao. 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 propriedade, 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 Apache, Tomcat, Jakarta AT&T Apple, Mac OS BSD Citrix Debian Firebird FreeBSD HP/UX IBM, Lotus, MVS, AIX, AS/400, VM/CMS, DB2, GLOBUS Interbase Borland Software Corporation Proprietrio Apache Foundation AT&T Apple Computer, Inc University of California, Berkeley, USA Citrix Systems, Inc. Software in the Public Interest, Inc Firebird Project Walnut Creek CDROM, Inc Hewlett-Packard Company IBM Corporation

VERSAO

1.0

PGINA 361

G UIA DE C LUSTER

CAPTULO B : M ARCAS R EGISTRADAS

Marcas Registradas MaxDB, MySQL, MySQL Cluster Windows, Active Directory, ODBC, Microsoft Exchange, SQL Server NetBSD Novell, Netware, NDS Adabas Oracle, OCFS, OCFS2 PostgreSQL, Slonny, pgpoll, pgcluster Red Hat, GFS, GNBD, RHCS SuSE Sun, Solaris, Java, JDBC Sybase Sequoia Zope

Proprietrio MySQL AB Microsoft Corporation NetBSD Foundation Novell, Inc Software/AG of North America, Inc Oracle Corporation PostgreSQL, Inc Red Hat, Inc SuSE AG Sun Microsystems, Inc Sybase, Inc Continuent, Inc Zope Corporation

Tabela B.1: Tabela de Referncia de Marcas Registradas

VERSAO

1.0

PGINA 362

Apndice C Lista de Abreviaturas

API APF ATM B2B B2C B2G BI BSP C2C C2G CC

Application Programming Interface Administrao Pblica Federal Assynchronous Transfer Mode Business to Business Business to Consumer business-to-government Business Inteligence Bulk Synchronous Parallelism consumer-to-consumer consumer-to-government Controle de Concorrncia

VERSAO

1.0

PGINA 363

G UIA DE C LUSTER

CAPTULO C : L ISTA DE A BREVIATURAS

CMOS DRAM DSM ECL e-GOV e-PING ERP FDDI FFT FTP G2G HA HIPPI HPC HPF HTTP

Complementary Metal Oxide Semiconductor Dynamic Random Access Memory Distributed Shared Memory Emmiter Coupled Logic Governo Eletrnico Brasileiro Arquitetura e-PING Padres de Interoperabilidade Enterprise Resource Planning Fiber Distributed Data Interface Fast Fourier Transformation Protocolo de Transferncia de Arquivo government-to-government Alta Disponibilidade High-Performance Parallel Interface Alta Capacidade de Processamento High Performance Fortran Protocolo de Transferncia de Hipertexto

VERSAO

1.0

PGINA 364

G UIA DE C LUSTER

CAPTULO C : L ISTA DE A BREVIATURAS

IP ISO LB LVS Mbps MFLOPS

Internet Protocol International Organization for Standardization Balanceamento de Carga Linux Virtual Server Milhes de bits por segundo Milhes de Instrues de Ponto Flutuante Por Segundo Mltiplas seqncias de Instrues, Mltiplas seqncias de Dados Milhes de Instrues Por Segundo Mltiplas Seqncias de Instrues, uma Seqncia de Dados Message Passing Interface Network File System Processadores Massivamente Paralelos NonUniform Memory Access On Line Transaction Processing Oracle Real Aplication Cluster Open Systems Interconnection

MIMD MIPS MISD

MPI NFS MPP NUMA OLTP Oracle RAC OSI

VERSAO

1.0

PGINA 365

G UIA DE C LUSTER

CAPTULO C : L ISTA DE A BREVIATURAS

PVM RFC RPCs RTP SAN SCI SGDB SIMD

Parallel Virtual Machine Request for Comments Remote Procedure Calls Real-time Transport Protocol Storage Area Network Scalable Coherent Interface Sistema Gerenciador de Banco de Dados Uma Seqncia de Instrues, Mltiplas Seqncias de Dados Uma Seqncia de Seqncia de Dados Instrues, uma

SISD

SLTI SMP SOA SOAP SONET SPMD SR

Secretaria de Logstica e Tecnologia da Informao Multiprocessadores Simtricos Arquitetura Orientada a Servios Protocolo Simples para Acesso a Objetos Synchronous Optical NETwork Simple Program Multiple Data Synchronizing Resources

VERSAO

1.0

PGINA 366

G UIA DE C LUSTER

CAPTULO C : L ISTA DE A BREVIATURAS

SRAM SSI TCP/IP TIC UDDI UDP VRRP W3C WSDL XDR XEN XML XMPP XSL

Static Random Access Memory Sistema de Imagem nica Transmition Control Protocol/Internet Protocol Tecnologia da Informao e Comunicao Descrio, Descoberta e Integrao Universais User Datagram Protocol Virtual Router Redundancy Protocol Consrcio da Rede Mundial Web Linguagem para denio de Servios Web External Data Representation Xen virtual machine monitor eXtensible Markup Language eXtensible Messaging and Presence Protocol eXtensible Stylesheet Language

Tabela C.1: Lista de Abreviaturas

VERSAO

1.0

PGINA 367

VERSAO

1.0

PGINA 368

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 Beowulf OpenSSI Kerrighed OpenMosix (Mosix) GPL v2 GPL v2 GPL v2 1.9.2 1.0.2 openMosixkernel2.4.26 Storage iSCSI gndb drdb endb gfs ocfs2 pvfs lustre GPL GPL GPL GPL GPL GPL GPL GPL 6.1 1.2.3 1.6.3 1.4.7 4.0.x 6.1 0.7
http://linux-iscsi.sourceforge.net/ http://sourceware.org/cluster/gnbd/ http://www.drbd.org/ http://www.it.uc3m.es/ptb/nbd/ http://www.redhat.com/software/rha/gfs/ http://oss.oracle.com/projects/ocfs2/ http://www.parl.clemson.edu/pvfs/ http://www.lustre.org/

Licena

Verso

Site Ocial HPC


http://www.beowulf.org/ http://www.openssi.org/ http://www.kerrighed.org/ http://openmosix.sourceforge.net/

Cluster de Banco de Dados, Banco de Dados Distribuido mysql cluster VERSAO 1.0 GPL e proprietria 5.0
http://www.mysql.com/products/database/ cluster/
PGINA 369

G UIA DE C LUSTER

CAPTULO D : T ECNOLOGIAS

Software pgcluster slony-l pgpool-I pgpool-II sequoia pargres

Licena BSD BSD BSD BSD Apache License 2 GPL

Verso 1.3 1.1.5 3.1.1 1.0.1 2.10

Site Ocial
http://pgcluster.projects.postgresql.org/ index.html http://gborg.postgresql.org/project/ slony1/projdisplay.php http://pgpool.projects.postgresql.org/ http://pgpool.projects.postgresql.org/ pgpool-II/en/ http://sequoia.continuent.org/HomePage

http://pargres.nacad.ufrj.br/

Alta Disponibilidade/Balanceamento de Carga Heartbet Carp LVS Keepalive GPL BSD GPL GPL 1.2.1 1.1.12 2.0.7
http://www.linux-ha.org/ http://www.openbsd.org/faq/pf/pt/carp. html http://www.linuxvirtualserver.org/ http://www.keepalived.org/

Cluster de Aplicaes Cluster ZOPE Cluster Tomcat cluster Apache ganglia Etherboot Apache License 2 Apache License 2 Ferramentas de Gerenciamento de Cluster BSD GPL v2 3.0
http://ganglia.sourceforge.net/ http://etherboot.sourceforge.net/

ZPL

3.1

http://zope.delta.ncsu.edu/portal/delta/ developers/projects/system_projects/zope_ cluster

5.0 2.0

http://jakarta.apache.org

http://httpd.apache.org

Tabela D.1: Tabela de referncias de tecnologias

VERSAO

1.0

PGINA 370

VERSAO

1.0

PGINA 371

G UIA DE C LUSTER

CAPTULO E : G LOSSRIO

Apndice E Glossrio
API (Application Programming Interface) O mtodo especco recomendado por um sistema operacional de computador, aplicativo ou ferramenta de terceiros, pelo qual um programador escrevendo um aplicativo pode fazer requisies do sistema operacional. Tambm conhecido por Application Programmers Interface. APF - Administrao Pblica Federal rene rgos da administrao direta (servios integrados na estrutura administrativa da Presidncia da Repblica e dos Ministrios) e indireta (Autarquias, Empresas Pblicas, Sociedades de Economia Mista e Fundaes Pblicas) do Poder Executivo. https://www.planalto.gov.br/ccivil_ 03/decreto-lei/del0200.htm Assncrona O que no ocorre ao mesmo tempo; sem relao regular de tempo, inesperado, imprevisvel. Modo de transmisso no qual os dados so transmitidos sem periodicidade constante (no modo sncrono, os dados so transmitidos periodicamente); transmisso de sinais onde os intervalos de tempo entre os caracteres transmitidos podem ser diferentes, e a transmisso controlada por elementos que indicam o incio e o m de cada caractere. Transmisso que envia um caractere de cada vez. Transmisso assncrona a transmisso de dados que no exige o uso de sinais externos para manter a sincroniVERSAO

1.0

zao entre emissor e receptor.

PGINA 372

Bandwidth (largura de banda)

Termo que designa o tempo gasto pelas vrias tecnolo-

G UIA DE C LUSTER

CAPTULO E : G LOSSRIO

Business to Business (B2B)

Negcios feitos entre empresas, seus clientes, distribuidores e fornecedores, conectando seus sistemas de informao atravs da Internet.

Business to Consumer (B2C)

Negcios feitos das empresas com seus consumidores, ou seja, comrcio eletrnico com o consumidor nal.

CERN

(Conseil

Europen

Um dos mais importantes centros mundiais de pesquisas avanadas em Fsica Nuclear e de Partculas, localizado em Genebra/Suia. Um de seus pesquisadores, Tim Berners Lee, foi o inventor, em 1989, do HTTP (Hypertext Transfer Protocol), o protocolo usado na WWW para transferir arquivos HTML.

pour la Recherche Nuclaire / Conselho Europeu para a Pesquisa Nuclear)

CERT (Computer Emergency Response Team)

Organizao criada em 1988 que oferece servios de consulta para usurios da Internet e que entra em ao sempre que um novo vrus e outras ameaas ao computadores so descobertas.

CORBA (Common Object Request Broker Architecture)

um padro para comunicao entre objetos distribudos. Prov diferentes formas para executar programas (objetos) desenvolvidos em diferentes linguagens de programao e em diferentes plataformas.

CRP (Continuous Replenishment Process)

a prtica de parceria entre os membros do canal de distribuio 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 uxo de informaes e produtos.

VERSAO

1.0

PGINA 373

G UIA DE C LUSTER

CAPTULO E : G LOSSRIO

Customer Relationship Management (CRM)

Gerenciamento do relacionamento com cliente a arte de integrar todos os aspectos da tecnologia da informao em benefcio de um completo relacionamento com o cliente, desde atividades de marketing e vendas at contas a receber.

Data warehouse

Armazm de dados, sistema que guarda e organiza todas as informaes espalhadas pelos vrios sistemas dentro de uma empresa. Termo genrico para um tipo de banco de dados que consiste num sistema de armazenamento, recuperao e gerenciamento de grandes quantidades de quaisquer tipos de dados. Os softwares da espcie freqentemente incluem sosticadas tcnicas, inclusive de compactao, para buscas mais rpidas de dados, assim como ltros avanados.

DNS - Domain Name System (Sistema de Nomes de Domnio)

forma como os nomes de domnio so encontrados e traduzidos no endereo de protocolo da Internet. Um nome de domnio um recurso fcil de ser lembrado quando referenciado como um endereo na Internet.

EAI (Enterprise Application Integration)

Integrao de Aplicaes entre Empresas um tipo de tecnologia que permite o movimento e troca de informaes entre diferentes aplicaes e processos de negcios entre e dentro de organizaes.

EDI (Electronic Data Interchange)

Intercmbio Eletrnico de Dados - tecnologia, que permite troca de informaes (com modem e softwares adequados) diretamente de computadores para computadores, dispensando digitao e manipulao de dados. O sistema que a utiliza permite automatizar transaes comuns de negcios como ordens de compras, faturas, noticaes de embarques etc. Atravs do EDI, documentos so transmitidos e recebidos eletronicamente, independente de horrios, distncia e dos sistemas de computao utilizados. O resultado um uxo de informaes rpido e preciso, no qual as mensagens vo e voltam sem qualquer interferncia e com toda segurana, atendendo aos desaos de maior agilidade e ecincia na comunicao de negcios.

VERSAO

1.0

PGINA 374

G UIA DE C LUSTER

CAPTULO E : G LOSSRIO

EJB (Enterprise JavaBeans)

um padro de programao Java que permite que cdigos escritos nesta linguagem e que sigam este padro, possam ser distribudos e executados em servidores de aplicao de EJB (EJB Servers).

ERP (Enterprise Resource Planning)

Planejamento de recursos corporativos atravs de sistemas integrados de gesto implementados por softwares; um programa integrado de gesto empresarial, geralmente dividido em diversos mdulos, como o de administrao, o nanceiro, de manufatura etc.

FTP - File Transfer Protocol (Protocolo de Transferncia de Arquivo) HTTP - Hyper Text Transfer Protocol (Protocolo de Transferncia de Hipertexto) IEEE - Institute of Electrical and Electronics Engineers (Instituto de Engenheiros Eltricos e Eletrnicos) IETF - Internet Engineering Task Force (Fora Tarefa de Engenharia da Internet) Internet

um protocolo aplicativo que utiliza os protocolos TCP/IP da Internet, sendo a maneira mais simples de trocar arquivos entre computadores na Internet. conjunto de regras para permuta de arquivos (texto, imagens grcas, som, vdeo e outros arquivos multimdia) na World Wide Web. fomenta o desenvolvimento de padres e normas que freqentemente se tornam nacionais e internacionais.

entidade que dene protocolos operacionais padro da Internet, como o TCP/IP.

Rede mundial de computadores que utiliza a arquitetura de protocolos de comunicao TCP/IP. Originou-se de um sistema de telecomunicaes descentralizado criado 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, navegao na Web e outros servios.

VERSAO

1.0

PGINA 375

G UIA DE C LUSTER

CAPTULO E : G LOSSRIO

JDBC

Java Database Connectivity. Uma especicao de interface de programa aplicativo (application program interface - API) para conectar programas escritos em Java aos dados em bancos de dados populares. A interface de programa aplicativo permite que se codiquem 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 dados se tornem teis. informao essencial para que se possa fazer uso dos dados. Em suma, metadados so um conjunto de caractersticas sobre os dados que no esto normalmente includas nos dados propriamente 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 diferentes podem comunicar-se atravs do servio de Messaging, proporcionado por programas middleware.

NFS (Network File System)

o protocolo de compartilhamento de arquivos remotos desenvolvido pela Sun Microsystems. Faz parte da famlia de protocolos TCP/IP.

NNTP (Network News Transfer Protocol) ORBs (Object Request Brokers)

Padro usado para a troca de mensagens dos usurios da Usenet na Internet. o componente responsvel por atender requisies de objetos em um framework de objetos. Principal componente da arquitetura CORBA, ele recebe requisies de clientes e disponibiliza o acesso objetos previamente publicados em um diretrio de objetos.

VERSAO

1.0

PGINA 376

G UIA DE C LUSTER

CAPTULO E : G LOSSRIO

Padro aberto

todo o padro tecnolgico estabelecido por rgos internacionais ou por consrcios de empresas do mercado que desenvolvem especicaes que se encontram publicamente disponveis. O PC (computador pessoal) foi lanado e desenvolvido com padro aberto. As especicaes da Internet e seu desenvolvimento tambm. A grande maioria das linguagens de programao tambm.

RFC - Request for Comments (Solicitao de Comentrios)

documento formal da IETF, resultante de modelos e revises de partes interessadas. A verso nal do RFC tornou-se um padro em que nem comentrios nem alteraes so permitidos. As alteraes podem ocorrer, porm, 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 procedimento ou programa que no se encontra na mesma mquina do programa chamador.

SOA - Service Oriented Architecture (Arquitetura Orientada a Servios)

Arquitetura proposta para interoperabilidade de sistemas por meio de conjunto de interfaces de servios fracamente acoplados (loosely coupled), onde os servios no necessitam de detalhes tcnicos da plataforma dos outros servios para a troca de informaes ser realizada.

SOAP - Simple Object Access Protocol (Protocolo Simples para Acesso a Objetos)

descreve um modelo para o empacotamento de perguntas e respostas XML.O envio de mensagens SOAP utilizado 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 usurios e fornecedores de servios.

VERSAO

1.0

PGINA 377

G UIA DE C LUSTER

CAPTULO E : G LOSSRIO

Software Livre

programa de computador disponvel atravs de seu cdigo-fonte e com a permisso para qualquer um uslo, copi-lo e distribu-lo, seja na sua forma original ou com modicaes, seja gratuitamente ou com custo. O software livre necessariamente no proprietrio, mas importante no confundir software livre com software grtis.

UDDI - Universal Description Discovery and Integration (Descrio, Descoberta e Integrao Universais) W3C - World Wide Web Consortium (Consrcio da Rede Mundial Web)

o repositrio no qual os desenvolvedores registram os Web Services disponveis que permitem aos clientes a descoberta e a utilizao dos servios alocados em Extranets e Intranets. associao de indstrias que visa promover padres para a evoluo da web e interoperabilidade entre produtos para WWW produzindo softwares de especicao e referncia.

Web Services

Aplicao lgica, programvel que torna compatveis entre si os mais diferentes aplicativos, independentemente do sistema operacional, permitindo a comunicao e intercmbio de dados entre diferentes redes.

WSDL - Web Services Denition Language (Linguagem para denio de Servios Web) WWW ou Web (World Wide Web)

um formato XML para descrio de servios web e suas informaes para acesso. Ela descreve as funcionalidades dos servios oferecidos pelo provedor de servios, bem como sua localizao e forma de acesso. rea da Internet que contm documentos em formato de hipermdia, uma combinao de hipertexto com multimdia. Os documentos hipermdia da WWW so chamados de pginas de Web e podem conter textos, imagens 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.

VERSAO

1.0

PGINA 378

G UIA DE C LUSTER

CAPTULO E : G LOSSRIO

XML - eXtensible Markup Language (Linguagem Markup Extensvel)

maneira exvel para criar formatos de informaes comuns e compartilhar ambos os formatos e os dados na World Wide Web, nas intranets e em qualquer lugar. O XML extensvel porque, diferentemente do HTML, os smbolos markup so ilimitados e se autodenem.

XMPP - eXtensible Messaging and Presence Protocol (Protocolo de Mensageria em Tempo Real) XSL - eXtensible Stylesheet Language

Protocolo aberto, baseado em XML para mensagens em tempo real.

linguagem de criao de planilhas que descreve como um dado mandado por meio da web, usando o XML, e apresentado ao usurio. O XSL uma linguagem para formatar um documento XML.

VERSAO

1.0

PGINA 379

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 hardware e software para os projetos internos ou em parceria com a Secretaria de Logstica e Tecnologia da Informao. O laboratrio um ambiente de testes, prospeco 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 governamentais. O processo de minerao de dados tem como principais objetivos descobrir relacionamentos, geralmente no triviais, entre dados armazenados, fornecer subsdios 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. 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 identicar inconsistncias e fraudes no acervo de bases de dados sociais do governo. Foram utilizadas as bases: SISOBI, SIM, GFIP, CADUNICO e do Censo Previdencirio. O acervo de dados tratado neste projeto da ordem de 300 milhes de registros, com possibilidade de expanso para at 1 bilho de registros.
VERSAO

1.0

PGINA 380

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 ): hospedagem 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 governamentais baseada em padres abertos e Web Services. Guia de administrao de ambientes em Cluster e Grid" : este documento possui um conjunto de justicativas para a adoo de tecnologias baseadas em computao distribuda pelo governo brasileiro e uma abordagem tcnica e gerencial das tecnologias de Cluster de Processamento de Alto Desempenho, Cluster de Aplicao, Cluster e replicao de Banco de Dados, Cluster de Armazenamento, Grid de saco-de-tarefas, Virtualizao de recursos computacionais. Testes, anlises e prospeco tecnolgica: foram realizados testes, anlises e prospeces tecnolgicas das tecnologias de Processamento de Alto Desempenho (MPI e PVM), Sistema de Arquivos Compartilhados (GFS, OCFS2, OCFS), Cluster de Banco de Dados (Oracle RAC, Sequoia, PgCluster, Pargres), Cluster de Aplicao (Linux Virtual Server, HeartBeat, CARP), Virtualizao 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 denir 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, denio 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 2

E-Ping - Padres de Interoperabilidade de Governo Eletrnico. Guia de Referncia de Migrao para software livre do Governo Federal
1.0 PGINA 381

VERSAO

G UIA DE C LUSTER

F.1 - H ISTRICO DO L AB C LUSTER

Eletrnico aos cidados, racionalizao do uso de recursos pblicos em tecnologia 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 dicultava 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 prprio ministrio para atender a demanda de otimizao de compras governamentais 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 nanciamento 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 conguradas como um Cluster de processamento baseado em tecnologia PVM4 . Os resultados deste projeto foram muito proveitosos e a Secretaria resolveu investir 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 4

http://tamandua.speed.dcc.ufmg.br/ Parallel Virtual Machine - Mquina paralela virtual


1.0 PGINA 382

VERSAO

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, baseada 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 provas de conceito, projetos piloto e no deve ser tratado como um ambiente de produo. 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 Livre 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 especcas de projetos, que no sero Software Livre ou aberto, mas a infra-estrutura de software base ser totalmente 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.

VERSAO

1.0

PGINA 383

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 conguraes dos hardwares disponveis no LabCluster, enquanto as sees subseqentes apresentam o detalhamento das conguraes disponveis:
Servidores SuperMicro 1U Memria HD 02 GB 01 x IDE 80GB Servidores SuperMicro 2U CPU Memria HD 02 x 2.4Ghz Xeon HT 04 GB 01 x IDE 80GB Servidor SuperMicro Gabinete CPU Memria HD 02 x 2.4Ghz Xeon HT 02 GB 04 x IDE 200GB Desktops Novadata CPU Memria HD 01 x 2.4Ghz Pentium 256MB 01 x IDE 40GB IV Servidor Dell PowerEdge 1850 CPU Memria HD 02 x 3.6Ghz 02 GB 01 x SCSI 73GB CPU 02 x 2.4Ghz Xeon HT Tabela F.1: Tabela de Hardware

Quant. 16 Quant. 08 Quant. 08 Quant. 12

Rede 02 x Gigabit Rede 10 x Gigabit Rede 02 x Gigabit Rede 01 100Mbps

Quant. 08

Rede 02 x Gigabit

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 interessados com o laboratrio. Ele possui os seguintes objetivos:

Denir qual a misso do LabCluster, Descrever os procedimentos de uso do ambiente LabCluster, Especicar a Infra-estrutura fsica e lgica, de hardware e software do LabCluster, Denir as polticas e normas de utilizao do LabCluster,
VERSAO

1.0

PGINA 384

G UIA DE C LUSTER

F.5 - P OLTICA DE U TILIZAO DO A MBIENTE L AB C LUSTER

Denir 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

VERSAO

1.0

PGINA 385

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 http: colaborativa no wiki do seminrio de cluster e grid
//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:
VERSAO

1.0

PGINA 386

G UIA DE C LUSTER

CAPTULO G : O UTROS D OCUMENTOS P RODUZIDOS

Guia do Usurio Sequoia, Manual OpenMosix, How-to PGcluster,

VERSAO

1.0

PGINA 387

Referncias Bibliogrcas
[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.


18/slony.html.

http://www.onlamp.com/pub/a/onlamp/2004/11/

[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. mini-HOWTO/.
http://www.austintek.com/LVS/LVS-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.
VERSAO

1.0

PGINA 388

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. 1599/0/1/0/.
http://www.linux-mag.com/content/view/

[21] RMI - remote method invocation specication. 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 overow vulnerability. http:// www.securityfocus.com/bid/7292/info/, April 2003. [30] Entropia web page. http://www.entropia.com, 2004.
VERSAO

1.0

PGINA 389

G UIA DE C LUSTER

REFERNCIAS BIBLIOGRFICAS

[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 lm talent.
se3d-overview.html, 2005. http://www.hpl.hp.com/SE3D/

[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 parametric 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: Federated, available, and reliable storage for an incompletely trusted environment. 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 Parallel Programming, 1993. [46] G. Agha. ACTORS: A Model of Concurrent Computation in Distributed Systems. Mit Press, 1986.
VERSAO

1.0

PGINA 390

G UIA DE C LUSTER

REFERNCIAS BIBLIOGRFICAS

[47] G. Actors AGHA. MIT Press, Cambridge, MA. A Model of Concurrent Computation in Distributed Systems, 1986. [48] Marcos Aguilera, Ramaprabhu Janakiraman, and Lihao Xu. Using erasure codes efciently 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 (Scientic 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 specication. GGF GridFTP Working Group Document, September 2002. [52] W. Allcock, A. Chervenak, I. Foster, C. Kesselman, and C. Salisbury S. Tuecke. The data grid: Towards an architecture for the distributed management and analysis of large scientic datasets. Journal of Network and Computer 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. Miller, 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 distributed le systems. Dez 1996. [57] T. Bray and J. Paoli and C. M. Sperberg-McQueen. Extensible Markup Language (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
VERSAO

1.0

PGINA 391

G UIA DE C LUSTER

REFERNCIAS BIBLIOGRFICAS

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 freeriding 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 approach 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 Roisenberg. Ourgrid: An approach to easily assemble grids with equitable resource sharing. 9th Workshop on Job Scheduling Strategies for Parallel Processing, June 2003. [63] Gregory ANDREWS. Synchronizing resources. ACM Transactions on Programming Languages and Systems, 3(4):405430, october 1981. [64] Gregory ANDREWS. The distributed programming language sr - mechanisms, design and implementation. Software-Practice and Experience, 12(8):719753, august 1982. [65] Gregory R. Andrews. Synchronising resources. ACM Transactions on Programming 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 Systems, 10(1):5186, january 1988. [68] Ronald A. ANDREWS, Gregory R.; OLSSON. The SR Programming Language. 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 Administration, 1965.
VERSAO

1.0

PGINA 392

G UIA DE C LUSTER

REFERNCIAS BIBLIOGRFICAS

[70] Eliane Arajo, Walfredo Cirne, Gustavo Wagner, and Nigini Oliveira. The seghidro experience: Using the grid to empower a hydro meteorological scientic 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: International efforts in Grid Computing, 2000. [74] Jennifer G. BAL, Henri E.; STEINER. Programming languages for distributed computing systems. ACM Computing Surveys, 21(3):261322, september 1989. [75] F. Banaei-Kashani, C. Chen, and C. Shahabi. Wspds: Web services peer-topeer 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. Metacomputing 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: Metacomputing 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.
VERSAO

1.0

PGINA 393

G UIA DE C LUSTER

REFERNCIAS BIBLIOGRFICAS

[81] P. Barham, B. Dragovic, K. Fraser, S. Hand, T. Harris, A. Ho, R. Neugebar, I. Pratt, and A. Wareld. 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 integration, 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 computational 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 Cluster, volume 1, chapter High Performance Cluster Computing. Prentice Hall, may 1999. [86] O. Beaumont, L. Carter, J. Ferrante, and Y. Robert. Bandwidth-centric allocation of independent task on heterogeneous plataforms. In Proceedings of the Internetional Parallel and Distributed Processing Symposium, Fort Lauderdale, 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. Applicationlevel 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 Research, 28:235242, 2000.
VERSAO

1.0

PGINA 394

G UIA DE C LUSTER

REFERNCIAS BIBLIOGRFICAS

[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 serverless distributed le 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 recongurable distributed memory multiprocessor. SpringerVerlang, 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 management architecture for computational power grids. In International Conference 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 Heterogeneous 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
VERSAO

1.0

PGINA 395

G UIA DE C LUSTER

REFERNCIAS BIBLIOGRFICAS

computational grid. In The 4th International Conference on High Performance Computing in Asia-Pacic 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 Symposium 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 Thakur. Pvfs: A parallel virtual le 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 scheduling. 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 schedule and deploy independent tasks in grid environments. In Proceedings of Workshop on Distributed Computing/Metacomputing and Resource Globalization, 2002. [111] H. Casanova, A. Legrand, D. Zagorodnov, and F. Berman. Heuristics for scheduling parameter sweep applications in grid environments. In Proceedings of the 9th Heterogeneous Computing Workshop, pages 349363, Cancun, Mexico, May 2000. IEEE Computer Society Press.
VERSAO

1.0

PGINA 396

G UIA DE C LUSTER

REFERNCIAS BIBLIOGRFICAS

[112] H. Casanova and L. Marchal. A network model for simulation of grid application. 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 performance 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. Alves B. da Silva, C. O. Barros, and C. Silveira. Running bag-of-tasks applications 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.


VERSAO

1.0

PGINA 397

G UIA DE C LUSTER

REFERNCIAS BIBLIOGRFICAS

[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. bittorrent.com/bittorrentecon.pdf, 2004.

http://www.

[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, novembro:16, 1997. [127] F. P. Coyle. Web Services, and the Data Revolution. Addison-Wesley Information 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 Programming, 1993. [130] f. Culler. Parallel Computer Architecture: A Hardware/Software Approach. Morgan Kaufmann, San Francisco, CA, 1998. [131] F. Curbera, Y. Goland, J. Klein, F. Leymann, D. Roller, S. Thatte, and S. Weerawarana. 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 wsresource 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.
VERSAO

1.0

PGINA 398

G UIA DE C LUSTER

REFERNCIAS BIBLIOGRFICAS

[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 ambiente 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. Comisso 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 Desempenho. 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 Desempenho - 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 Desempenho - 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 Desempenho - 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 Desempenho - Canoas - RS. Comisso Regional de Alto Desempenho - Regional do Rio Grande do Sul, Sociedade brasileira de Computao, 2005.
VERSAO

1.0

PGINA 399

G UIA DE C LUSTER

REFERNCIAS BIBLIOGRFICAS

[146] Escola Regional de Alto Desenpenho. Sexta Escola Regional de Alto Desempenho - 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. RICHARD, 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, INTERNATIONAL CONFERENCE ON FIFTH GENERATION COMPUTER SYSTEMS, 1984. [149] Jay L. Devore. Probability and Statistics for Engineering and The Sciences, volume 1. John Wiley and Sons, Inc., 2000. [150] Peter Dibble, Michael Scott, and Carla Ellis. Bridge: A high-performance le 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 software livre do governo federal. http://www.governoeletronico.gov.br. Ultima 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 February 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 University Press, 1998.
VERSAO

1.0

PGINA 400

G UIA DE C LUSTER

REFERNCIAS BIBLIOGRFICAS

[157] Andrea C. Dusseau, David E. Culler, Klaus E. Schauser, and Richard P. Martin. Fast parallel sorting under logp: Experience with the cm-5. IEEE Transactions on Parallel and Distributed Systems, 7(8):791805, 1996. [158] Csar A. F. De Rose e Philippe O. A. Navaux. Arquiteturas Paralelas. Instituto 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 nal 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 protocols 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. Manning 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 Computing 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 ock 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 ock 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 servers. 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.
VERSAO

1.0

PGINA 401

G UIA DE C LUSTER

REFERNCIAS BIBLIOGRFICAS

[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 evaluation. 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 parallel 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 toolkit. International Journal of Supercomputer Applications, 11(2):115128, 1997. [182] I. Foster and C. Kesselman. The globus project: A status report. In Proceedings of IPPS/SPDP Heterogeneous Computing Workshop, pages 418, 1998.
VERSAO

1.0

PGINA 402

G UIA DE C LUSTER

REFERNCIAS BIBLIOGRFICAS

[183] I. Foster and C. Kesselman, editors. The Grid: Blueprint for a Future Computing 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 Computing, 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.
http://tomcat.

[188] The Apache Software Foundation. Apache 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 Proceedings 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 computation management agent for multi-institutional grids. In High Performance Distributed Computing, 2001. Proceedings. 10th IEEE International Symposium, pages 55 63, San Francisco, CA, USA, August 2001. IEEE Computer Society Press. [192] Doreen L. Galli. Distributed Operating Systems. Prentice Hall, 2000. [193] E. Gamma, R. Helm, R. Johnson, and J. Vlissides. Design Patterns. AddisonWesley 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.
VERSAO

1.0

PGINA 403

G UIA DE C LUSTER

REFERNCIAS BIBLIOGRFICAS

[195] Cludio F.R GEYER. Une contribution a letude du parallelisme ou en prolog 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 google le 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 proler for use by parallel schedulers. Lecture Notes in Computer Science, 1291:5877, 1997. [199] Dan Gisol. 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 donar o mainframe e busca solues em software http://www.serpro.gov.br/noticiasSERPRO/ 20060829_02/. TI & Governo, no 170, 29 de agosto de 2006. abanlivre.

[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 vision 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.
VERSAO

1.0

PGINA 404

G UIA DE C LUSTER

REFERNCIAS BIBLIOGRFICAS

[209] Ibrahim F. Haddad. Pvfs: A parallel virtual le system for linux clusters. 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 processing applications. In 3rd IEEE/ACM Internetional Symposium on Cluster Computing and the Grid, 2003. [212] A. Hefez. Curso de lgebra, volume 1. IMPA, 1993. [213] F HERMENEGILDO, M.; ROSSI. Prolog and its Performance: Exploiting Independente 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 le 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. home.html, December 2003.
http://www.crpc.rice.edu/HPFF/

[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 evaluation of wsrf and ws-notication via wsrf.net. In Proc. of the 5th IEEE/ACM International Workshop on Grid Computing, 2004.
VERSAO

1.0

PGINA 405

G UIA DE C LUSTER

REFERNCIAS BIBLIOGRFICAS

[221] k. Hwang. Advanced computer architecture: parallelism, scalability, programmability. Mcgraw-hill, New York, NY, 1993. [222] Kai HWANG. Advanced Computer Architecture: Parallelism, Scalability, Programmability. 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 location in grid environments. Grid Resource Management, 2003. [225] Adriana Iamnitchi, Matei Ripeanu, and Ian Foster. Small-world le-sharing communities, March 2004. [226] Oscar H. Ibarra and Chul E. Kim. Heuristic algorithms for scheduling independent 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/. Ultima Visita em 20.04.2005 12:20. [229] Virglio Jos Martins IGNACIO, Anbal Alberto Vilcapona y FERREIRA FILHO. Mpi: uma ferramenta para implementao paralela. Pesquisa Operacional, 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 specication 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.

Ultima Visita em 20.09.2005 12:12. [233] ISO. International organization for standardization. http://www.iso.org. Ultima Visita em 20.04.2005 12:20.
VERSAO

1.0

PGINA 406

G UIA DE C LUSTER

REFERNCIAS BIBLIOGRFICAS

[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 experimental 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 implementation of the pasda parallel le system. In International Conference on Parallel and Distributed Systems, chapter pages 142 - 147. 1994. [238] Paul JONES, Mark P.; HUDAK. Implicit and explicit parallel programming in haskell. nebula.systemsz.cs.yale.edu/pub/yale-fp/reports/RR982.ps.Z. julho de 1999. [239] T. Jones, A. Koniges, and R. K. Yates. Performance of the ibm general parallel le 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: Conning the omnipotent root. In Proceedings of 2nd International System Administration and Networking Conference, May 2000. [242] Subramanian Kannan, Mark Roberts, Peter Mayes, Dave Brelsford, and Joseph 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. Efcient robust parallel computations (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 le systems past, present and future a distributed le system for 2006. http://choices.cs.uiuc.edu/~f-kon/DFSPaper. ps.gz. Ultima Visita em 20.09.2005 12:12.
VERSAO

1.0

PGINA 407

G UIA DE C LUSTER

REFERNCIAS BIBLIOGRFICAS

[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 protocols 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 Proceedings of the Ninth International Conference on Architectural Support for Programming 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: Specication and renement in maude. In Computer Science, editor, Recent Trends in Data Type Specications, 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 ow 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.


VERSAO

1.0

PGINA 408

G UIA DE C LUSTER

REFERNCIAS BIBLIOGRFICAS

[257] M. Litzkow, M. Livny, and M. Mutka. Condor: A hunter of idle workstations. 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 Distributed Computing Systems, June 1988. [259] V. Lo, J. Mache, and K. Windisch. A comparative study of real workload traces and synthetic workload models for parallel job scheduling. In D. Feitelson 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 chiers 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 server 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. Subhlok. 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 mobile 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. Dynamic matching and scheduling of a class of independent tasks onto heterogeneous computing systems. In 8th Heterogeneous Computing Workshop, pages 3045, San Juan, Puerto Rico, April 1999.
VERSAO

1.0

PGINA 409

G UIA DE C LUSTER

REFERNCIAS BIBLIOGRFICAS

[267] K. Marzullo, M. Ogg, A. Ricciardi amd A. Amoroso, A. Calkins, and E. Rothfus. Nile: Wide-area computing for high energy physics. In Proceedings 7th ACM European Operating Systems Principles Conference. System Support for Worldwide Applications, pages 5459, Connemara, Ireland, September 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 Rogrio 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 Architeture 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 le system for massivelyparallel 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, highperformance parallel le 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.
VERSAO

1.0

PGINA 410

G UIA DE C LUSTER

REFERNCIAS BIBLIOGRFICAS

[277] Dan I MOLDOVAN. Parallel Processing From Applications to Systems. Morgan 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 General Public Licence, 2003. [280] H. Stephen MORSE. Practical Parallel Computing. Academic Press, Inc, 1994. [281] M. V MUTHUKUMAR, K.; HERMENEGILDO. Complete and efcient methods for supporting side-effects in independent/restricted andparallelism. In INTERNATIONAL CONFERENCE ON LOGIC PROGRAMMING, 1989. [282] M. V MUTHUKUMAR, K.; HERMENEGILDO. Determination of variable dependence information through abstract interpretation. In NORTH AMERICAN 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 le system. 1987. [286] Zsolt Nemeth and Vaidy Sunderam. A formal framework for dening 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 cluster nodes for execution of independent grid tasks. In Proceedings of the rst international conference on e-Science and grid computing, pages 238245, Melbourne, 2005. IEEE Computer Society. [289] Marco Aurlio Stelmar Netto and Csar A.F. De Rose. CRONO: A congurable and easy to maintain resource manager optimized for small and
VERSAO

1.0

PGINA 411

G UIA DE C LUSTER

REFERNCIAS BIBLIOGRFICAS

mid-size GNU/Linux cluster. In Proceedings of the 2003 International Conference 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. Fileaccess characteristics of parallel scientic workloads. IEEE Transactions on Parallel and Distributed Systems, 7(10):10751089, october 1996. [292] R. Novaes, P. Roisenberg, R. Scheer, C. Northeet, J. Jornada, and W. Cirne. Non-dedicated distributed environment: A solution for safe and continuous exploitation of idle cycles. In Proceedings of the AGridM 2003 - Workshop on Adaptive Grid Middleware, 2003. [293] R. Oldeld. 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 system. ABriefRetrospectiveontheSpriteNetworkOperatingSystem. Ultima Visita em 20.09.2003 12:12. [297] S.P. Pacheco. A users guide to mpi. http://nexus.cs.usfca.edu/mpi/. Ultima Visita em 20.04.2005 12:20. [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.
VERSAO

1.0

PGINA 412

G UIA DE C LUSTER

REFERNCIAS BIBLIOGRFICAS

[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 le-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 computing. 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/. Ultima Visita em 20.04.2005 12:20. [308] Harish Ramachandran. Design and implementation of the system interface 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 scheduling in distributed data-intensive applications. In High Performance Distributed Computing, 2002. Proceedings. 11th IEEE International Symposium, Edinburg, 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 HighPerformance Distributed Computing, July 1998. [312] C. Rolland. Latex: Guide Pratique. Addison-Wesley France, SA, 1995.
VERSAO

1.0

PGINA 413

G UIA DE C LUSTER

REFERNCIAS BIBLIOGRFICAS

[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 desempenho. In ERAD 2002 - 2a Escola Regional de Alto Desempenho, Janeiro 2002. [315] Rob Ross, Walt Ligon, , and Phil Carns. Parallel virtual le 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. Shadbolt. The evolution of the Grid. Int. J. of Concurrency and Computation: Practice and Experience, to appear. [318] Antony I. T. Rowstron and Peter Druschel. Storage management and caching in PAST, a large-scale, persistent peer-to-peer storage utility. In Symposium 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 performance of data intensive grid applications. In Proceedings of Research Colloquium on Third IFIP Conference, September 2003. [321] E. Santos-Neto, W. Cirne, F. Brasileiro, and A. Lima. Exploiting replication and data reuse to efciently 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 ber. 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.
VERSAO

1.0

PGINA 414

G UIA DE C LUSTER

REFERNCIAS BIBLIOGRFICAS

[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. jailint.html, 2001.
http://www.daemonnews.org/200109/

[327] Mahadev Satyanarayanan, James J. Kistler, Lily B. Mummert, Maria R. Ebling, Punnet Kumar, and Qi Lu. Experience with disconnected operation 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 mechanism 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 Scientic Computing, 1997. [330] S. Shepler, B. Callaghan, D. Robinson, R. Thurlow, C. Beame, M. Eisler, and D. Noveck. Network le 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: University Press, 1994. [333] Domenico SKILLICORN, David B.; TALIA. Models and languages for parallel computation. ACM Computing Surveys, 30(2):123169, june 1998. [334] Joseph D. Sloan. Ten tips for building your rst 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.
VERSAO

1.0

PGINA 415

G UIA DE C LUSTER

REFERNCIAS BIBLIOGRFICAS

[336] S. Smallen, W. Cirne, and J. Frey et. al. Combining workstations and supercomputers to support grid applications: The parallel tomography experience, 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 environments. 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 le system. http://www.diku.dk/undervisning/2003e/314/papers/ soltis97global.pdf. Ultima Visita em 20.09.2005 12:12. [342] I. Sommerville. Software Engineering. GmbH, 6th edition, 2001. Pearson Education Deutschland

[343] S. Son and M. Livny. Recovering internet symmetry in distributed systems 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.
VERSAO

1.0

PGINA 416

G UIA DE C LUSTER

REFERNCIAS BIBLIOGRFICAS

[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 fullling 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 operacionais: projeto e implementao. Bookman, 1999. Maarten Van. TANENBAUM, Andrew S.; STEEN. Distributed systems: principles and paradigms. Prentice Hall, 2002.

[353]

[354] PVFS2 Development Team. Parallel virtual le 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 Symposium 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: Making the Global Infrastructure a Reality. John Wiley and Sons Inc., December 2002. [359] Alok THAKUR, Rajeev; CHOUDHARY. Efcient algorithms for array redistribution. IEEE Transactionson Parallel and Distributed Systems, 6(7):587 594, june 1996.
VERSAO

1.0

PGINA 417

G UIA DE C LUSTER

REFERNCIAS BIBLIOGRFICAS

[360] Rajeev Thakur. Romio: A high-performance, portable mpi-io implementation. 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 Proceedings of the IEEE High Performance Distributed Computing Conference (HPDC9), 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 lowcomplexity 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 nal 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. Maquire, T. Sandholm, P. Vanderbilt, and D. Snelling. Open grid services infrastructure (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 Computing, 1998.
VERSAO

1.0

PGINA 418

G UIA DE C LUSTER

REFERNCIAS BIBLIOGRFICAS

[371] L. G VALIANTE. A bridging model for parallel computation. Communications 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 lesystem. 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 Collaborative Research. In Juha Fagerholm, Juha Haataja, Jari Jrvinen, Mikko Lyly, Peter Raback, and Ville Savolainen, editors, The Sixth International Conference 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 Distributed 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 monitoring 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 monitoring 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 benets of wide-area computing for parallel processing. Journal of Parallel and Distributed Computing, 54(2), November 1998.
VERSAO

1.0

PGINA 419

G UIA DE C LUSTER

REFERNCIAS BIBLIOGRFICAS

[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 Tuecke. 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. Ultima 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. Ultima 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 timeshared unix systems on the computational grid. In Proceedings of 8th International 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 Explorao do Paralelismo. 2006.
VERSAO

1.0

PGINA 420

G UIA DE C LUSTER

REFERNCIAS BIBLIOGRFICAS

[394] Yifeng Zhu, Hong Jiang, Xiao Qin, Dan Feng, and David R. Swanson. Improved read performance in ceft-pvfs: Cost efective, fault-tolerant parallel virtual le system. http://www.cs.nmt.edu/~xqin/pubs/ccgrid03. pdf. Ultima Visita em 20.09.2005 12:12.

VERSAO

1.0

PGINA 421

You might also like