Documenti di Didattica
Documenti di Professioni
Documenti di Cultura
~yt~c~~iO$
~CtrCt~igVVt,Ct$
2 edi900
Andrew S. Tanenbaum
Maarten Van Steen
Tradu~ao
Arlete Simille Marques
Engenheira Qufmica -
UFPR
Revisao Tecnica
. Wagner Luiz Zucchi
Professor doutor do Departamento de Sistemas Eletronicos da
Escola Politecnica da Universidade de Sao Paulo
PEARSON
Prentice
Hall
Sumario
Prefacio IX
1. Introducao
1.1 Definiao de urn sistema distribuido
1.2 Metas
1.3 Tipos de sistemas distribufdos
1.4 Resumo
1
2
10
18
2.1
2.2
2.3
2.4
Estilos arquitet6nicos
Arquiteturas de sistemas.................................................................................................................................................................
Arquiteturas versus middleware
Autogerenciamento em sistemas distribufdos.:
20
22
32
35
3.1
3.2
3.3
3.4
3.5
3.6
Threads
Virtual izaao
Clientes
Servidores
Migraao de c6digo
Resumo
42
48
50
53
62
67
4.1
4.2
4.3
4.4
4.6
Fundamentos
Chamada de procedimento remoto
Comunicaao orientada a mensagem
Comunicaao orientada a fluxo
Resumo
69
75
84
95
105
5.1
5.2
5.3
5.4
5.5
108
110
118
131
137
6.1
6.2
6.3
6.4
6.5
6.6
Sincronizaao de rel6gios
Re16gios 16gicos.......................................................................................................................
Exclusao mutua
Posicionamento global de n6s
Algoritmos de eleiao
Resumo
140
147
152
157
159
163
7.1
7.2
7.3
7.4
7.5
7.6
Introduao
Modelos de consistencia centrados em dados
Modelos de consistencia centrados no cliente
Gerenciamento de replicas
Protocolos de consistencia
Resumo
165
167
174
178
185
191
194
198
8.3
8.4
8.5
8.6
8.7
203
207
215
220
226
9.1
9.2
9.3
9.4
9.5
Introdur;ao 11 seguranr;a
Canais seguros
Controle de acesso
Gerenciamento da seguranr;a
Resumo
228
240
250
259
266
10.1
10.2
10.3
10.4
10.5
10.6
10.7
10.8
10.9
Arquitetura
Processos
Comunicar;ao
N omear;ao
Sincronizar;ao
Consistencia e replicar;ao
Tolerancia a falba
Seguranr;a
Resumo
11.1
11.2
11.3
11.4
11.5
11.6
11.7
11.8
11.9
Arquitetura
Processos
Comunicar;ao
N omear;ao
Sincronizar;ao
Consistencia e replicar;ao
Tolerancia a falha
Seguranr;a
Resumo
12.1
12.2
12.3
12.4
12.5
12.6
12.7
12.8
12.9
Arquitetura
Process os
Comunicar;ao
Nomear;ao
Sincronizar;ao
Consistencia e replicar;ao
Tolerancia a falha
Seguranr;a
Resumo
268
272
275
281
284
285
288
291
294
296
302
303
306
310
314
320
322
328
330
335
339
344
345
346
353
354
355
357
358
364
364
365
367
367
371
374
375
377
382
Prefacio
Sistemas distribuidos sao uma area da ciencia da computa<;ao que esta mudando rapidamente. Nos ultimos anos vem
surgindo novos t6picos muito interessantes, como computa<;ao peer-to-peer e redes de sensores, enquanto outros
amadureceram muito, como servi<;os Web e aplica<;6es Web em geral. Mudan<;as como essas exigiram uma revisao de
nosso texto original para que ficasse atualizado.
Esta segunda edi<;ao reflete uma grande revisao em compara<;ao com a anterior. Adicionamos urn capitulo especifico
sobre arquiteturas, que reflete 0 progresso alcan<;ado na organiza<;ao de sistemas distribuidos. Vma outra diferen<;a
importante e que, agora, ha muito mais material sobre sistemas descentralizados, em particular computa<;ao peer-to-peer.
Nao nos limitamos a discutir apenas as tecnicas basicas, mas tambem demos aten<;ao as suas aplica<;6es, como
compartilhamento de arquivo, divulga<;a? de informa<;6es, redes de entrega de conteudo e sistemas publicar/subscrever.
Assim como esses dois assuntos importantes, ainda discutimos novos assuntos em todo 0 livro. Por exemplo,
adicionamos material sobre redes de sensores, virtualiza<;ao, clusters de servidores e computa<;ao em grade. Demos
aten<;ao especial ao autogerenciamento de sistemas distribuidos, urn t6pico cada vez mais importante dado 0 continuo
crescimento da escala desses sistemas.
Certamente, modemizamos 0 material on de foi adequado. Por exemplo, quando discutimos consistencia e
replica<;ao, era agora focalizamos modelos de consistencia mais apropriados para sistemas distribuidos modemos mais
do que os modelos originais, que foram talhados para computa<;ao distribuida de alto desempenho. Da mesma maneira,
adicionamos material sobre modemos algoritmos distribuidos, entre eles algoritmos de sincroniza<;ao de rel6gio e de
localiza<;ao baseados em GPS.
Embora isso nao seja comum, conseguimos reduzir 0 numero total de paginas. Essa redu<;ao e causada, em parte,
pela exclusao de assuntos como coleta distribuida de lixo e protocol os de pagamento eletr6nico, e tambem pela
reorganiza<;ao dos quatro ultimos capitulos.
Como na edi<;ao anterior, 0 livro e dividido em duas partes. Principios de sistemas distribuidos sao discutidos do
Capitulo 2 ao Capitulo 9, enquanto as abordagens globais dos modos de desenvolvimento de aplica<;6es distribufdas (os
paradigmas) sao discutidas do Capitulo 10 ao Capitulo 13. Entretanto, diferente da edi<;ao anterior, decidimos nao
discutir estudos de casos completos nos capftulos dedicados a paradigmas. Em vez disso, agora cada principio e
explicado por meio de urn caso representativo. Por exemplo, invoca<;6es de objeto sao discutidas como urn principio de
comunica<;ao no Capitulo 10 sobre sistemas distribufdos baseados em objetos. Essa abordagem nos permitiu condensar
o material, mas tambem tomou a leitura e 0 estudo mais agradaveis.
Claro que continuamos a recorrer extensivamente a prMica para explicar 0 que sao, afinal, sistemas distribufdos.
Varios aspectos de sistemas utilizados na vida real, como WebSphere MQ, DNS, GPS, Apache, Corba, Ice, NFS,
Akamai, TIBlRendezvous, Jini e muitos outros sao discutidos em todo 0 livro. Esses exemplos ilustram a tenue divisao
entre teoria e pratica, que toma a area de sistemas distribufdos tao interessante.
Muitas pessoas contribufram para este livro de divers as maneiras. Gostarfamos de agradecer em especial a
D. Robert Adams, Amo Bakker, Coskun Bayrak, Jacques Chassin de Kergommeaux, Randy Chow, Michel Chaudron,
Puneet Singh Chawla, Fabio Costa, Cong Du, Dick Epema, Kevin Fenwick, Chandana Gamage, Ali Ghodsi, Giorgio
Ingargiola, Mark Jelasity, Ahmed Kamel, Gregory Kapfhammer, Jeroen Ketema, Onno Kubbe, Patricia Lago, Steve
MacDonald, Michael J. McCarthy, M. Tamer Ozsu, Guillaume Pierre, Avi Shahar, Swaminathan Sivasubramanian,
Chintan Shah, Ruud Stegers, Paul Tymann, Craig E. Wills, Reuven Yagel e Dakai Zhu pel a leitura de partes do
manuscrito e por terem ajudado a identificar erros cometidos na edi<;ao anterior e oferecido comentarios uteis.
Por fim, gostarfamos de agradecer a nossas farmlias. Ate agora, Suzanne ja passou por esse processo dezessete
vezes. E muito para mim, mas tambem para ela. Ela nunca disse: "Agora, chega!", embora eu tenha certeza de que teve
vontade de dizer. Obrigado. Agora, Barbara e Marvin tern uma ideia muito melhor do que professores fazem para viver
e sabem quais sao as diferen<;as entre urn born e um mau livro didMico. Agora eles sao uma inspira<;ao para eu tentar
produzir mais bons do que maus livros (AST).
Como tirei uma licen<;a para atualizar 0 livro, 0 trabalho de escrever tambem ficou muito mais agradavel para
Marielle. Ela esta apenas come<;ando a se acostumar com ele, mas continua a me dar suporte e a me alertar quando e
tempo de voltar rninha aten<;ao a assuntos mais importantes. Eu the devo muito. A essa altura, Max e Elke ja tem uma
ideia muito melhor do que significa escrever um livro, porem, em cornpara<;ao com 0 que eles mesmos estao lendo,
acham diffcil entender 0 que ha de tao interessante nessas coisas estranhas que chamamos sistemas distribufdos. E eu
nao posso culpa-Ios (MvS).
Companion Website
i
o
'0
Introdu~ao
Os sistemas de computac;ao estao passando por uma
revoluc;ao. Desde 1945, quando comec;ou a era modem a
dos computadores, ate aproximadamente 1985, os computadores eram grandes e caros. Mesmo os minicomputadores custavam no minimo dezenas de milhares de d6lares cada. 0 resultado e que a maioria das organizac;6es
tinha apenas alguns poucos computadores e, na falta de
urn modo de conecta-Ios, eles funcionavam independentemente uns dos outros.
Contudo, mais ou menos a partir de meados da decada de 1980, dois avanc;os tecnol6gicos comec;aram a mudar
es a situac;ao. 0 primeiro foi 0 desenvolvimento de microprocessadores de grande capacidade. De infcio, eram
maquinas de 8 bits, mas logo se tomaram comuns CPUs de
16,32 e 64 bits. Muitas dessas CPUs tinham a capacidade
de computac;ao de urn mainframe - isto e, urn grande
computador central-,
mas por uma frac;ao do prec;o dele.
A quantidade de melhorias que ocorreu na tecnologia
de computadores nos ultimos 50 anos e verdadeiramente
as ombrosa e totalmente sem precedentes em outros setore . De uma maquina que custava dez milh6es de d61ares
e executava uma instruc;ao por segundo, chegamos a
maquinas que custam mil d61ares e podem executar urn
bilhao de instruc;6es por segundo, urn ganho prec;o/desempenho de 1013. Se os carros tivessem melhorado nessa proporc;ao no mesmo periodo de tempo, urn Rolls Royce custaria agora urn d61ar e faria urn bilhao de milhas por galao.
(Infelizmente, e provavel que tamMm tivesse urn manual
de 200 paginas para ensinar como abrir a porta.)
o segundo desenvolvimento foi a invenc;ao de redes
de computadores de alta velocidade. Redes locais, ou
LANs (local-area networks), permitem que centenas de
maquinas localizadas dentro de urn ediffcio sejam conectadas de modo tal que pequenas quantidades de informac;ao possam ser transferidas entre maquinas em alguns
microssegundos, ou algo parecido. Maiores quantidades
de dados podem ser movimentadas entre maquinas a
taxas de 100 milh6es a 10 bilh6es de bits/so Redes de
longa distancia, ou WANs (wide-area networks), permitem que milh6es de maquinas no mundo inteiro se
conectem a velocidades que variam de 64 Kbits/s a gigabits por segundo.
Um sistema distribufdo
um conjunto de computadores independentes que se apresenta a seus
usuarios como um sistema unico e coerente.
Figura 1.1
vel colocar quatro drives de disco flexfvel em urn computador pessoal. A questao e que nao teria sentido fazer isso.
Nesta sec;ao, discutiremos quatro metas importantes que
devem ser cumpridas na construc;ao de urn sistema distribUldo para que valha a pen a 0 esforc;o. Urn sistema distribuldo deve oferecer facil acesso a seus recursos; deve
ocultar razoavelmente bem 0 fato de que os recursos SaG
distribufdos por uma rede; deve ser aberto e deve poder
ser expandido.
A principal meta de urn istema distribufdo e facilitar aos usuanos, e as aplica<;:6es, 0 acesso a recursos
remotos e seu compartilhamenro de maneira controlada e
eficiente. Os recursos podem ser muito abrangentes, mas
entre os exemplos tfpicos estao impressoras."computadores, facilidades de armazenamento, dados, paginas Web e
redes, s6 para citar alguns. Ha muitas raz6es para querer
compartilhar recursos, e uma razao 6bvia e a economia.
Por exemplo, e mais barato perrnitir que uma impressora
seja compartilhada por diversos usuanos em urn pequeno
escrit6rio do que ter de comprar e manter uma impressora direcionada a cada usuano. Do mesmo modo, em termos econornicos, faz sentido compartilhar recursos de
alto custo como supercomputadores, sistemas de armazenamento de alto desempenbo, images etters e outros perifericos caros.
Conectar usuarios e recursos tambem facilita a colaborac;ao e a troca de informac;6es, 0 que e claramente ilustrado pelo sucesso da Internet com seus protocolos simples para trocar arquivos, correio, documentos, audio e
vfdeo. Agora, a conectividade da Internet esta Ievando a
vanas organizac;6es virtuais nas quais grupos de pessoas
muito dispersas geograficamente trabalham juntas por
meio de groupware, isto e, software para edic;ao colaborativa, teleconferencia e assim por diante. Da mesma
maneira, a conecti idade da Internet possibilitou 0 comercio eletronico, que nos perrnite comprar vender todos os
tipos de mercadoria sem ter de realmente ir a uma Ioja ou
ate mesmo sair de casa.
Contudo, a medida que a conectividade e 0 compartilhamento crescem, a seguranc;a se torna cada vez mais
importante.
a prlitica corrente, os sistemas ofere cern
pouca protec;ao contra bisbilhotice ou intrusao na comunicac;ao. Senhas e outras informac;6es sensfveis muitas
vezes sao enviadas como texto comum - isto e, nao criptografado - pela rede, ou armazenadas em servidores
que podemos apenas esperar que sejam confiaveis. Nesse
sentido, ha muito espac;o para melhorias. Por exemplo,
hoje e posslvel fazer pedidos de mercadorias informando
apenas urn numero de cartao de credito.'Raramente e soIicitada uma prova de que 0 cliente seja 0 proprietario do
cartao. No futuro, fazer pedidos desse modo s6 sera posslvel se voce realmente provar que possui 0 cartao em
maos, inserindo-o em uma Ieitora de cart6es.
Transparencia
cesso
de dados e
LocaJizagao
Migragao
Relocagao
e replicado
Replicagao
Concorrencia
Falha
Tabela 1.1
de um recurso
Transparencia
de acesso trata de ocultar diferenc;as
em representa~ao de dados e 0 modo como os recursos
podem ser acessados por usuarios. Em urn nivel basico,
desejamos ocultar diferen~as entre arquiteturas de maquinas, porem 0 mais importante e chegar a urn acordo sobre
como os dados devem ser representados por maquinas e
sistemas operacionais diferentes. Por exemplo, urn sistema distribuido pode ter sistemas de computac;ao que executam sistemas operacionais diferentes, cada urn com
suas proprias conven~6es para nomea~ao de arquivos.
sistente. Pode-se conseguir consistencia por meio de travas de acesso, 0 que da a cada usuario, urn por vez, acesso exclusivo ao recurso desejado. Urn mecanismo mais
refinado e utilizar transa~oes; porem, como veremos em
capftulos posteriores, e bastante diffcil implementar transa~oes em sistemas distribufdos.
Uma defini~ao alternativa e popular de urn sistema
distribufdo, devida a Leslie Lamport, e "Voce sabe que tern
urn quando a falha de urn computador do qual nunca ouviu
falar impede que voce fa~a qualquer trabalho". Essa descri~ao pontua uma outra questao importante no projeto de
sistemas distribufdos: como tratar falhas. Fazer com que
urn sistema distribufdo seja transparente a falha significa que urn usuario nao percebe que urn recurso (do qual
possivelmente nunc a ouviu falar) deixou de funcionar bem
e que, subseqiientemente, 0 sistema se recupero.u da falha.
Mascarar falhas e uma das questoes mais diffceis em sistemas distribufdos e ate mesmo impossfveis de se realizar
quando sao adotadas certas prernissas aparentemente realistas, como discutiremos no Capftulo 8. A principal dificuldade para mascarar falhas esta na incapacidade de distinguir entre urn recurso morto e urn recurso insuportavelmente lento. Por exemplo, quando contatamos urn servidor
Web ocupado, a certa altura 0 tempo do browser se esgotara e ele avisara que a pagina Web nao esta disponfvel.
Nesse ponto, 0 usuario nao pode concluir se, na verdade,
o servidor esta avariado.
Embora a transparencia de distribui~ao seja geralmente considerada preferfvel para qualquer sistema distribufdo, ha situa~oes em que tentar ocultar completamente
dos usuanos todos os aspectos da distribui~ao nao e uma
boa ideia. Urn exemplo e requisitar que seu jornal eletronico apare~a em sua caixa postal antes das 7 horas da
manha, hora local, como sempre, enquanto naquele
momenta voce esta no outro lado do mundo, onde 0 fuso
horario e diferente. Seu jornal matutino nao seraaquele ao
qual voce esta acostumado.
Da mesma maneira, nao se pode esperar que urn sistema distribufdo de longa distancia que conecta urn processo em San Francisco a urn processo em Amsterda
oculte 0 fato de que a Mae Natureza nao permitira que ele
envie uma mensagem de urn processo para 0 outro em
menos do que aproximadamente 35 milissegundos. Na
pratica, quando se esta usando uma rede de computadores, isso levara varias centenas de rnilissegundos. A transrnissao de sinal nao somente esta lirnitada pela velocidade
da luz, mas tambem pelas capacidades de processamento
dos comutadores intermedianos.
Tambem ha urn comprornisso entre urn alto grau de
transparencia e 0 desempenho de urn sistema. Por exemplo, muitas aplica~oes de Internet tentam contatar urn servidor repetidas vezes antes de finalmente desistir. Por
conseqiiencia, tentar mascarar uma falha transit6ria de
A conectividade mundial pela Internet esta rapidamente se tornando tao comum quanta poder enviar urn
cartao-postal para qualquer pessoa em qualquer lugar do
Exemplo
Servi90s centralizados
Algoritmos
centralizados
A escalabilidade geognifica tern seus pr6prios problemas. Vma das principais raz6es por que hoje e diffcil
ampliar sistemas distribufdos existentes que foram originalmente projetados para redes locais e que eles saG
baseados em cornunica~ao sincrona. Nessa forma de
omunica<;ao, uma parte que requisita urn servi<;o, em
geral denominada cliente, fica bloqueada ate que uma
mensagem seja enviada de volta. Essa abordagem costuma
funcionar bem em LANs nas quais a comunica<;ao entre
duas maquinas, na pior das hip6teses, demora, comumente, algumas centenas de microssegundos. Todavia, em urn
i tema de longa distancia, precisamos levar em conta que
a comunica<;ao entre processos pode demorar centenas de
milissegundos, isto e, ela e tres ordens de grandeza mais
lenta. Construir aplica<;6es interativas usando comunica~o sfncrona em sistemas de longa distanciarequer muito
uidado, alem de muita paciencia.
Urn outro problema que atrapalha a escalabilidade
geografica e que a comunica<;ao em redes de longa distania e inerentemente nao confiavel e quase sempre ponto a
ponto. Por compara<;ao, redes locais em geral proporcionam facilidades de comunica<;ao de alta confian<;a com
ase em broadcast, 0 que facilita muito 0 desenvolvimen'0 de sistemas distribufdos.
Considere 0 problema de
ocalizar urn servi<;o. Em urn sistema de area local, urn
rocesso pode simplesmente enviar uma mensagem
broadcast a todas as maquinas, perguntando a cada uma
e esta executando 0 servi<;o de que ele necessita. Somente as maquinas que tern aquele servi<;o respondem, cada
uma delas fornecendo seu endere<;o de rede na mensagem
de resposta. Tal esquema de localiza<;ao e inconcebfvel
em urn sistema de longa distancia: imagine s6 0 que aconteceria se tentassemos localizar urn servi<;o desse modo
na Internet. Em vez disso, e preciso projetar servi<;os
especiais de localiza<;ao, que talvez tenham alcance mundial e sejam capazes de atender a bilh6es de usuarios.
Voltaremos a abordar esses servi<;os no Capftulo 5.
A escalabilidade geografica esta forte mente relacionada com problemas de solu<;6es centralizadas que atrapalham a escalabilidade de tamanho. Se tivermos urn sistema com muitos componentes centralizados, e claro que
a escalabilidade geografica estara limitada pelos problemas de desempenho e confiabilidade resultantes da comunica<;ao a long a distancia. Alem disso, nessa circunstancia
os componentes centralizados resultarao em desperdfcio
de recursos de rede. Imagine que urn unico servidor de
correio seja usado por urn pafs inteiro. Isso significaria
que, quando voce enviasse urn e-mail aseuvizinho.primeiro 0 e-mail teria de ir ate 0 servidor central de correio,
que poderia estar a qui16metros de distancia. Claro que
esse nao e 0 melhor caminho.
Por fim, uma questao diffcil e, em muitos casos, ainda
aberta e como ampliar urn sistema distribufdo por vanos
dominios administrativos independentes. Urn problema
irnportante que precisa ser resolvido e 0 de polfticas con-
Ap6s discutirmos alguns problemas de escalabilidade, surge a questao de como resolve-los de maneira geral.
Na maioria dos casos, problemas de escalabilidade em sistemas distribufdos aparecem como problemas de des empenho causados por capacidade limitada de servidores e
rede. Agora, ha basicamente apenas tres tecnicas para
ampliar sistemas: ocultar latencias de comunica<;ao, distribui<;ao e replica<;ao [ver tambem Neuman (1994)].
Ocultar latencias de comunica<;ao e importante para
conseguir escalabilidade geografica. A ideia basica e simples: tentar evitar, 0 quanta possfvel, esperar por respostas a requisi<;6es remotas - e potencialmente distantes de servi<;os. Vamos supor que urn servi<;o seja requisitado
em uma maquina remota. Uma alternativa a esperar por
uma resposta do servidor e executar outro trabalho Util no
lado do requisitante. Em essencia, is so significa construir
a aplica<;ao requisitante de modo tal que ela use s6 cornunica~ao assincrona. Quando chega uma resposta, a aplica<;aoe interrompida e urn manipulador especial e chamado para concluir a requisi<;ao emitida anteriormente.
A comunica<;ao asslncrona muitas vezes pode serusada
em sistemas de processamento de.lotes e em aplica<;6esparalelas, nos quais tarefas mais ou menos independentes podem
ser escalonadas para execu<;ao enquanto uma outra tarefa
esm esperando pela conclusao da comunica<;ao. Como alternativa, pode-se iniciar urn novo thread de controle para exe-
Primeiro nome
IMAARTEN
Ultimo nome
IVAN STEEN
ISTEEN@CS.VU.NL
[Q]
Verifique
formulario
IMAARTEN
IVAN STEEN
ISTEEN@CS.VU.NL
I
I
I
[Q]
..
I
'1f
,
Venflque
formulario
Processe
formulario
....
\
Processe
formulario
distribufdo
as seguintes premissas falsas que todos ado tam ao desenvolver uma aplica~ao distribufda pela primeira vez:
1.
2.
3.
4.
5.
A rede e confiavel.
A rede e segura.
A rede e homogenea.
A topologia nao muda.
A latencia e zero.
6. A largura de banda e infinita.
7. 0 custo de transporte e zero.
B. Ha so urn administrador.
Observe como essas premissas se referem a propriedades exclusivas de sistemas distribufdos: confiabilidade,
seguran~a, heterogeneidade e topologia da rede; latencia
e largura de banda; custos de transporte e,por fim, domfnios administrativos. No desenvolvimento de aplica~6es
nao distribufdas, e provavel que a maioria dessas quest6es
nem apare~a.
A maior parte dos princfpios que discutimos neste
livro esta imediatamente relacionada a essas premissas.
Em todos os casos, discutiremos solu~6es para problemas
causados pelo fato de uma ou mais premissas serem falsas. Por exemplo, redes confiaveis simples mente nao
.existem, 0 que leva a impossibilidade de conseguir transparencia a falha. Dedicaremos urn capftulo inteiro para
tratar do fato de que a comunica~ao por rede e inerentemente insegura. Ja discutimos que sistemas distribufdos
precisam levar em conta a heterogeneidade. N a mesma
toada, quando discutimos replica~ao para resolver problemas de escalabilidade, estamos, em essencia, atacando
problemas de latencia e largura de banda. Tambem abordaremos quest6es de gerenciamento em varios pontos
desta obra, tratando das falsas premissas do transporte a
custo zero e de urn unico domfnio administrativo.
Aplicac;:ao de
gerenciamento
Rede de
acesso remoto
Componente
da
aplicac;:ao
paralela
Componente
da
aplicac;:ao
paralela
Componente
da
aplicac;:ao .
paralela
as de computa~ao em grade
Urn aspecto caracterfstico da computa~ao de cluster
_ _ bomogeneidade. Na maioria dos casos, os computa- '- que comp6em urn cluster s3oo,em grande parte, as
-esmos, todos tern a mesmo sistema operacional e todos
_ -0 onectados a mesma rede. Par compara~3oo, sistemas
~ omputac:;ao em grade tern alto grau de heterogeneidac:~: nenhuma premissa e adotada em rela~ao a hardware,
-.-=-Dmas operacionais, redes, dominios administrativos,
- liricas de seguran~a e assim par diante.
Uma questao fundamental em urn sistema de compu~~o em grade e que recursos de diferentes organiza~6es
-" reunidos para permitir a colabara~3oo de urn grupo de
?S oas au institui~6es. Tal colabora~3oo e realizada sob a
:orma de uma organiza~ao virtual. As pessoas que per-
ten cern a mesma organiza~3oo virtual tern direitos de acesso aos recurs as fomecidos par aquela organiza~ao. Entre
os recursos tipicos estao servidares de computa~ao (entre
eles supercomputadores, possivelmente implementados
como computadores de cluster), facilidades de armazenamenta e bancos de dados. Alem disso, tambem podem ser
oferecidos equipamentos especiais em rede, como telescapias, sensores e outros.
Dada a sua natureza, grande parte do software para
realizar computa~3oo em grade e desenvolvida com a finalidade de prover aces so a recursos de diferentes dominios
administrativos, e somente para usuarios e aplica~5es que
perten~am a uma organiza~3oo virtual especffica. Par essa
raz3oo,a foco costuma ser dirigido as quest5es de arquitetura. Uma arquitetura proposta par Foster et al. (2001) e
mostrada na Figura 1.5.
A arquitetura consiste em quatro camadas. A mais
baixa, denominada camada-base, prove interfaces para
recursos locais em urn site especffico. Observe que essas
interfaces S300projetadas para permitir compartilhamento
de recurs as dentro de uma arganiza~ao virtual. A tarefa
tipica dessas interfaces e prover fun~5es para consultar 0
estado e as capacidades de urn recurso, em conjunto com
fun~5es para 0 gerenciamento de recursos propriamente
dito. Par exemplo: travar recursos.
A camada de conectividade consiste em protocolos de
comunica~3oo para suportar transa~5es da grade que abranjam a utiliza~3oode mtiltiplos recursos. Par exemplo, S300
necessmos protocolos para transferir dados entre recursos,
au para a simples acesso de urn recurso desde uma localiza~3ooremota. Alem disso, a camada de conectividade contera protocolos de seguran~a para autenticar usumos e
recursos. Observe que, em muitos casas, usumos humanos
n300sao autenticados; em vez disso, S300autenticados programas que agem em nome dos usumos. Nesse sentido,
delegar direitos de urn usumo a programas e uma fun~3oo
importante que precisa ser suportada na camada de conectividade. Daremos mais detalhes sabre a delega~3ooquando
discutirmos seguran~a em sistemas distribuidos.
A camada de recursos e responsavel pelo gerenciamento de urn tinico recurso. Ela utiliza as fun~5es fomecidas pela
camada de conectividade e chama diretamente as interfaces
disponibilizadas pela camada-base. Par exemplo, essa cama-
Aplicac;:6es
-J-
Descri~ao
BEGIN_TRANSACTION
END_TRANSACTION
ABORT_TRANSACTION
READ
WRITE
BEGIN_TRANSACTION e END_TRANSACTION
usadas para delimitar 0 escopo de uma transa<;ao. As
<;6esentre elas formam 0 corpo da transa<;ao. 0 aspeccaracteristico de uma transa<;ao e que todas essas operasao executadas ou nenhuma e executada. Elas podem
:cr procedimentos de biblioteca, chamadas de sistema ou
-l
lara<;6esentre parenteses em uma linguagem, dependendo cia implementa<;ao.
Essa propriedade tudo-ou-nada das transa<;6es e uma
quatro propriedades caracteristicas que elas tern. Mais
especificamente, transa<;6es sao:
-
1. Atomicas: para
Subtransa9aO
Subtransa9ao
U U
Bancos de d~dos da\
companhla aerea
.
(independentes)
Quando os sistemas de middleware empresarial come9aram, 0 componente que manipulava transa90es distribuidas, ou aninhadas, formava 0 nueleo para a integra9ao de aplica90es no nivel do servidor ou do banco de
dados. Esse componente era denominado monitor de
processamento
de transa~ao, ou, de forma abreviada,
monitor TP. Sua principal tarefa era permitir que uma
aplica9ao acessasse varios servidoresfbancos de dados
oferecendo a ela urn modelo de programa9ao transacional, como mostra a Figura 1.7.
Existem varios tipos de middleware de comunica9ao. Com chamadas de procedimento remoto (Remote
Procedure Calls - RPC), urn componente de aplica9ao
pode efetivamente enviar uma requisi9ao a urn outro componente de aplica9ao executando uma chamada de procedimento local, que resulta no empacotamento da requisi9ao como uma mensagem e em seu envio ao chamador.
Da mesma forma, 0 resultado sera enviado de volta e
devol vido a aplica9ao como 0 resultado da chamada de
procedimento.
A medida que a popularidade da tecnologia de objeto aumentava, foram desenvolvidas tecnicas que permitissem chamadas a objetos remotos, 0 que resultou naquilo
que denominamos
invoca~oes
de metodo remoto
(Remote Method Invocations - RMI). Vma RMI e, em
essencia, 0 mesmo que uma RPC, exceto que fun cion a
com objetos em vez de com aplica90es.
A desvantagem da RPC e da RMI e que ambos, 0
chamador e 0 chamado, precisam estar ligados e em funcionamento no momenta da comunica9ao. Alem disso,
eles precis am saber exatamente como se referir urn ao
outro. Esse forte acoplamento muitas vezes e percebido
como uma seria desvantagem e resultou no que conhecemos como middleware orientado a mensagem ou, simplesmente, MOM (Message-oriented
Middleware).
Nesse caso, as aplica90es apenas enviam mensagens a
pontos 16gicos de contato, que frequentemente sao descritos por meio de urn sujeito. Da mesma forma, as aplica-
Aplicagao
c1iente
Aplicagao
c1iente
Aplicagao
dolado
servidor
Aplicagao
cliente
Aplicagao
dolado
servidor
Aplicagao
dolado
servidor
Adotar mudanc;:as contextuais significa que urn dis- -itivo deve estar continuamente ciente do fato de que
_0::1 ambiente po de mudar 0 tempo todo. Uma das mudan~.- mais simples e descobrir que uma rede nao esta mais
-sponlvel porque urn usuario esta se movimentando
estac;:6es-bases. Nesse caso, a aplicac;:ao deve reagir,
Urn tipo cada vez mais popular de sistema pervasivo, mas que talvez seja 0 menos restrito, sao sistemas
montados ao redor de redes domesticas. Em geral, esses
sistemas sao compostos de urn ou mais computadores
pessoais. Porem, 0 mais importante e que integram eletronicos de consumo tipicos como aparelhos de TV, equipamentos de audio e video, dispositivos parajogos, smart
phones, PDAs e outros equipamentos de uso pessoal em
urn tinico sistema. Alem disso, podemos esperar que
todos os tipos de dispositivos, como eletrodomesticos de
cozinha, camaras de vigiHincia, relogios, controladores
de iluminac;:ao e assim por diante, serao conectados a urn
tinico sistema distribuido.
Da perspectiva de sistema, ha varios desafios que precisam ser enfrentados antes que os sistemas pervasivos
domesticos se tornem realidade. Urn desafio importante e
que tal sistema deve ser completamente autoconfiguravel
e autogerenciavel. Nao se pode esperar que usuarios finais
estejam dispostos ou sejam capazes de manter urn sistema
distribuido domestico ligado e em funcionamento se seus
componentes forem propensos a erros, como acontece
com muitos dos dispositivos existentes hoje.
Muito ja foi conseguido por meio dos padr6es
Universal Plug and Play (UPnP), pelos quais dispositivos
obtem automaticamente enderec;:osIF, pod em descobrir uns
aos outros e assim por diante (UPnP Forum, 2003). Contudo, e precise mais. Por exemplo, nao esta claro como 0
software e 0 fIrmware presentes em dispositivos podem ser
atualizados com facilidade sem intervenc,;ao manual, ou
quando ocorrem as atualizac,;6es, de modo que a compatibilidade com outros dispositivos nao seja violada.
Vma outra questao premente e 0 gerenciamento daquilo que e conhecido como urn espafo pessoal. Reconhecendo que urn sistema domestico consiste em muitos
dispositivos compartilhados, bem como pessoais, e que os
dados em urn sistema domestico tambem estao sujeitos a
restric,;6es de compartilhamento, muita atenc,;aoe dedicada
a percepc,;ao desses espac,;os pessoais. Por exemplo, parte
do espac,;opessoal de Alice pode consistir em sua agenda,
fotos da familia, urn diario, musicas e videos que ela comprou etc. Esses ativos pessoais devem ser armazenados de
maneira que Alice tenha acesso a eles sempre que desejar.
Alem disso, partes desse espac,;o pessoal devem estar temporariamente - acessiveis a outros, como no caso de
ela precisar participar de uma reuniao de neg6cios.
Felizmente, as coisas podem fIcar mais simples. Ha
muito tempo considera-se que espac,;ospessoais relacionados com sistcmas domestic os sac inerentemente distribuidos por varios dispositivos. E 6bvio que tal dispersao
podera resultar facilmente em problemas de sincronizac,;ao. Todavia, esses problemas podem ser amenizados
devido ao rapido crescimento da capacidade de discos
rigidos, aliado a reduc,;aode seu tamanho. ConfIgurar uma
unidade de armazenamento de varios terabytes para urn
computador pessoal nao e, realmente, urn problema.
Da mesma maneira, discos rfgidos port::iteis com
capacidade de centenas de gigabytes estao sendo colocados dentro de reprodutores de midia port::iteis relativamente pequenos. Com 0 crescimento continuo dessas capacidades, e possivel que logo vejamos sistemas pervasivos
domestic os adotarem uma arquitetura na qual uma unica
maquina funcionara como mestra (e fIcara escondida em
algum lugar do porao, perto do aquecimentocentral)
e
todos os outros dispositivos fIxos sirnplesmente oferecerao
uma interface conveniente para os seres humanos. Entao,
,,
Sensor de inclira9ao
\
\
I
PDA
\
\
Figura 1.9
I
I
I
,,
/
/
Armazenamento
"
I
\
Sensor do ECG
"
'\\
I
\
de movimento
,,
I
I
Sensores
externo
Transmissor
) ~PRS/UM;S
\
I
\
\
,,
,
I
/
/
/
OU
devedo ser
armazenados?
2.. Como podemos evitar a perda de dados cruciais?
Qual e a infra-estrutura necessaria para gerar e
transmitir sinais de alerta?
.. Como os medicos podem dar retorno on-line?
Como po de ser alcan~ada a extrema robustez do
sistema de monitora~ao?
Quais saG as quest6es de seguran~a e como as
polfticas adequadas podem ser impostas?
Diferentemente dos sistemas domesticos, nao podee: perar que a arquitetura de sistemas pervasivos de
ento de saude tenda a passar para sistemas de urn
-~o ervidor e que seus dispositivos de monitora~ao
:::erem com funcionalidade mfnima. Ao contnirio: por
:!Zae de eficiencia, os dispositivos e redes de areas cor~ _. tedo de suportar processamento de dados na
e. 0 que significa que os dados de monitora~ao terao
-= er agregados antes de ser armazenados permanentete ou enviados a urn medico. Diferentemente do caso
2: temas de informa~ao distribufdos, ainda nao ha uma
-=s ta clara para essas quest6es.
Lado do operador
EJI~
sensores
sao enviados
diretamente
ao operador
Cada sensor
pode processar e
armazenar dados
Site do operador
[]
Figura 1.10
Organizando
:~nsore:<
enviam
somente
respostas
e processando dados (a) somente no site do operador ou (b) somente nos sensores.
6. Par que nem sempre e uma boa ideia visar a implementac;ao do mais alto grau de transparencia possivel?
7. 0 que e urn sistema distribuido aberto e quais sao as
beneficios que a abertura proporciona?
B. Descreva, com exatidao,
escalcivel.