1. Tópicos em redes e
sistemas distribuídos
Carlos Oberdan Rolim
Ciência da Computação
Sistemas de Informação

2. Aspectos de projeto
em sistemas distribuídos
[C1,T1.1,T1.2,T1.3,T1.4] (40 p.)

3. Conceitos e Arquiteturas

4. Sistemas Centralizados
Grande porte físico →
limitações para
acomodação
Grande consumo de
energia → sala
especial, refrigeração
SO único →
dependência do
fabricante
Terminais sem capacidade
de processamento (“burros”)
Computadores com grande
capacidade de processamento
(mainframes)
...passado...passado
Motivação

5. Sistemas em Rede
Computadores diversos,
todos com capacidade de
processamento
Portes diversos
SOs diversos
Redes diversas (Ethernet,
ATM, com fio, sem fio...)
Internet
A realidade dos últimos tempos...A realidade dos últimos tempos...
Motivação

6. Distribuição de sistemas
Dividindo para conquistar!!!Dividindo para conquistar!!!
A
B
C
D
Programa modularizado
Execução sequencial ou
concorrente (threads)
distribuir
Motivação

7. Dividindo para conquistar!!!Dividindo para conquistar!!!
A
B
C
D
Programa modularizado
A
B
C
D
Motivação
Distribuindo...

8. Programa distribuído
Componentes
interligados
(comunicação)
Processamento
(computação)
distribuído ou paralelo
Dividindo para conquistar!!!Dividindo para conquistar!!!
A
C
D
B
Motivação

9. Potencial para ser mais poderoso do que um sistema
centralizado, convencional
Pode ser mais confiável: toda função pode ser replicada
Quando um processador falha, outro pode continuar o trabalho
Se um disco dá crash, arquivos gravados também em outros discos não são
perdidos
Várias computações podem ser realizadas em paralelo: um
sistema distribuído pode realizar mais na mesma quantidade de
tempo
Pode-se considerar tolerância a falha e possibilidade de
paralelismo como as propriedades fundamentais de um
sistema distribuído

10. Definições
Lamport: “Um sistema distribuído é aquele que faz você parar de
ter o trabalho realizado quando uma máquina da qual você nunca
ouviu falar falha”
Mais seriamente, Tanenbaum e van Renesse (1985):
Um sistema (operacional) distribuído é aquele que aparece para os
usuários como um sistema (operacional) centralizado ordinário, mas que
executa em múltiplas CPUs independentes.
O conceito chave é transparência, ou seja, o uso de múltiplos
processadores deve ser invisível (transparente) para o usuário.
Pode-se dizer que o sistema é visto como um “uniprocessador virtual”, e
não como uma coleção de máquinas distintas.

11. Definições mais recentes
“Coleção de computadores
independentes que aparecem
para os usuários do sistema como
um único computador.”
(Tanenbaum & van Steen)
“Um sistema em que componentes
de hardware e software localizados
em computadores em rede se
comunicam e coordenam suas
ações por passagem de
mensagens.” (Coulouris et al)
Vários componentes
Conectados via uma rede
Compartilhando recursos
Transparência
• “Uma coleção de elementos
de processamento
interconectados, tanto
logicamente como
fisicamente, para execução
cooperativa de programas
de aplicação com o controle
geral dos recursos
centralizado.” (M. Eckhouse)

12. Por que construir SDs?
Pessoas são distribuídas, informação é distribuída
Desejo de comunicar e compartilhar informações e recursos
Relação desempenho/custo
Modularidade
Expansibilidade
Sistemas distribuídos são capazes de crescimento incremental
Disponibilidade
SDs têm capacidade de replicação e redundância

13. Por que construir... (cont)
Escalabilidade
Idealmente, sistemas distribuídos não devem ter qualquer componente
centralizado (cuja capacidade impõe limites para o tamanho máximo de
um sistema), tal que a restrição ao crescimento não deve existir
Confiabilidade
Disponibilidade é apenas um aspecto de confiabilidade
O sistema deve ser capaz de se recuperar de falhas

14. Complexidade
Complexidade limita o que pode ser construído
Schroeder chama os problemas causados pela complexidade de
problemas de sistema:
Interconexão: um grande número de problemas de sistemas acontece quando
componentes que antes operavam independentemente são interconectados
Interferência: dois componentes de um sistema, cada um com comportamento
razoável quando observados em isolamento, podem exibir comportamento
indesejável quando combinados
Propagação de efeito: “efeito cascata” de falhas pode derrubar um sistema
inteiro se não houver cuidados no projeto

15. Problemas de sistema (cont)
Efeitos de escala: um sistema que funciona bem com 10 nós pode
falhar se crescer para centenas de nós
Falha parcial
Grande diferencial de sistemas distribuídos em relação a sistemas
centralizados, tradicionais
Fonte considerável de complexidade no projeto de aplicações
tolerantes a falhas

16. Requisitos não-/funcionais como fonte de complexidade
Sistemas distribuídos são complexos porque o que eles têm que
fazer é complexo
Exemplos:
1. Gerenciamento do escalonamento de trens em uma rede em que passageiros
têm que trocar de trens para chegar em seus destinos – o problema da
sincronização
2. Sistema de arquivos distribuídos
É preciso prever aspectos como autenticação, controle de acesso,
controle de concorrência etc.
Complexidade ainda maior quando há os requisitos de alta
disponibilidade e tolerância a falhas
Aspectos como mecanismos de localização de arquivo, coordenação de
estado de servidor replicado, mecanismos de recuperação de falhas parciais
etc.

17. Necessidade econômica como fonte de complexidade
A solução simples nem sempre pode ser usada – às vezes é cara
demais!
Exemplo:
Em uma rede de longa distância, interconectar todos os pontos (nós) seria a
solução mais simples, porém extremamente cara!
A solução mais barata é fazer uma rede em que todos os nós são alcançáveis,
porém não necessariamente de forma direta
O custo dessa solução é mais baixo, porém a complexidade é bastante
aumentada: são necessários
algoritmos de roteamento,
“buferização” para gerenciar o tráfego multiplexado,
mecanismos de controle de fluxo para prevenir congestionamento etc.

18. Conceito-chave
Distribuição
Comunicação
Complexidade
Heterogeneidade
Transparênciademandam

19. Resumo
A maioria dos (grandes) sistemas (reais) de hoje precisam de
comunicação
Os sistemas precisam ser modularizados para melhor legibilidade
e menor complexidade no desenvolvimento
Do ponto de vista do usuário e do programador de aplicação, é
preciso transparência
Tolerância a falha e possibilidade de paralelismo são
propriedades fundamentais de um sistema distribuído
Boa relação desempenho/custo é um desafio alcançável
Continua...

20. Resumo (cont)
Características-chave:
Escalabilidade
Confiabilidade (disponibilidade, tolerância a falhas, segurança,...)
Falha parcial é um grande diferencial de sistemas distribuídos em
relação a sistemas centralizados/tradicionais, mas também é fonte
considerável de complexidade
Do ponto de vista de software, é preciso agregar outras
funcionalidades às que os sistemas operacionais convencionais
oferecem para dar suporte adequado a sistemas distribuídos

21. Sistemas Distribuídos
Características, Objetivos
e
Modelos Arquiteturais

22. Características
Conjunto de máquinas autônomas
Interconectadas por canais de comunicação
Comunicando-se por troca de mensagens
Independência de falhas (falhas parciais)
• Ausência de relógio global
• Ausência de estado global
• Estado compartilhado da aplicação (através
de comunicação)

23. Objetivos
Conexão de usuários e recursos
Desejo de comunicar e compartilhar informações e recursos
Transparência
Escalabilidade (scalability)
Abertura (openness)

24. Objetivos de um Projeto de SD
Eficiência – desempenho produtivo
Conveniência – utilidade e aplicabilidade
Robustez – resistência a falha
Disponibilidade: o sistema está no ar quando preciso (instante de
tempo)
Confiabilidade: o sistema não falha por um longo período de tempo
E quando falha, a falha não provoca uma “catástrofe”
Consistência – mesma visão de dados
Transparência

25. Tipos de Transparência
Localização: esconde onde o recurso está localizado
Acesso: operações idênticas para acesso local e remoto
Migração: esconde que um recurso pode se mover para outra localização
Relocação: esconde que um recurso pode ser movido para outra
localização enquanto está em uso
Concorrência: compartilhamento de recursos sem interferência entre
processos concorrentes
Falha: esconde a falha e recuperação de um recurso
Replicação: esconde de usuários ou programadores de aplicação a
existência de réplicas de recursos

26. Abertura
Capacidade de um sistema poder ser estendido (hw, sw) e de
interoperar com outros sistemas
Resulta da especificação de interfaces, de tornar as especificações
públicas e de padronizá-las
Especificações podem ser
padrões estabelecidos por organização de padronização
padrões estabelecidos pelo uso (de fato)

27. Limitações de escalabilidade: Exemplos
Conceito Exemplo
Serviços centralizados Um único servidor para todos os usuários
Dados centralizados Uma única lista telefônica on-line
Algoritmos centralizados Roteamento baseado em informação completa

28. Escalabilidade
Um sistema continuará eficaz mesmo havendo um aumento
significativo no número de recursos e de usuários
Desafios:
Controlar o custo de recursos
Controlar a perda de desempenho
Prevenir que os recursos acabem (ex., endereços IP)

29. Desafios de SDs
Heterogeneidade
Transparência
Tolerância a Falhas
Segurança
Escalabilidade
Concorrência
Abertura

30. Modelos Arquiteturais
Cliente-Servidor
Peer-to-Peer
Objetos Distribuídos

31. O que é um modelo arquitetural?
Estrutura em termos de componentes especificados
separadamente
Inter-relações de componentes
Divisão de responsabilidades entre componentes

32. Arquitetura Cliente-Servidor
… invocation
invocation
Results
Results
Clients
Server
… invocation
invocation
Results
Results
Clients
Servic
e
Servidor Único Múltiplos Servidores

33. C/S: Aspectos positivos
Arquiteturas cliente-servidor fornecem uma infra-estrutura
versátil que suporta a inserção de novas tecnologias mais
rapidamente
Arquiteturas de software cliente-servidor têm sido usadas
desde os anos 80 → maturidade

34. Objetos Distribuídos
Uma aplicação distribuída pode ser vista como um conjunto
de objetos
Objetos:
Consistem de dados + código
Podem ser clientes, servidores ou ambos
Interface esconde detalhes de implementação
Modelar com objetos não implica no uso de programação orientada a
objetos

35. TanenbaumandvanSteen.DistributedSystems:PrinciplesandParadigms
©PrenticeHall2002
Objetos Distribuídos
Observe a separação entre interface e objeto
Interface
local
Objeto
remoto

36. Peer processes (P2P)
Coordination
Application
code
Coordination
Application
code
Coordination
Application
code
Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3
© Addison-Wesley Publishers 2000

37. Escolhendo arquitetura...
Alguns tradeoffs devem ser considerados para selecionar a
arquitetura mais apropriada, incluindo:
O crescimento potencial do número de usuários,
Custo e
Homogeneidade do ambiente computacional futuro e do momento
Cliente-servidor é um modelo-base
Objetos distribuídos são uma evolução
Há várias interpretações de P2P: “semi-P2P”, “P2P puro”, ...

38. Plataformas de Software
Infra-estruturas para
Sistemas Distribuídos

39. Infra-estruturas de Software
Sistemas Operacionais Distribuídos
Sistemas Operacionais de Rede
Middleware

40. Introdução
Hardware é importante para sistemas distribuídos...
Software é o que melhor diferencia sistemas distribuídos
Sistemas distribuídos são como sistemas operacionais tradicionais
Atuam como gerentes de recursos, permitindo que múltiplos usuários ou
aplicações compartilhem CPUs, memórias, periféricos, rede e dados
Tentam esconder a heterogeneidade e complexidade do hardware (remoto,
principalmente) ao fornecer uma máquina virtual (software) onde aplicações
podem ser executadas mais facilmente

41. Sistemas operacionais para computadores distribuídos
Fortemente acoplados
Tentam manter visão única e global dos recursos gerenciados
Fracamente acoplados
Coleção de computadores, cada um executando seu próprio sistema
operacional
No entanto, estes sistemas operacionais trabalham juntos para tornar os
serviços e recursos de uns disponíveis aos outros

42. SOD, SOR e Middleware
Sistemas operacionais fortemente acoplados para sistemas
(computadores e programas) distribuídos, geralmente, são
chamados de sistemas operacionais distribuídos (SODs) –
visão única e global dos recursos
Sistemas operacionais fracamente acoplados são os sistemas
operacionais de rede (SORs) – cada computador executando seu
próprio SO, e vice-versa, um SO completo para cada computador
Para melhor suporte à transparência de distribuição são
necessários melhoramentos ou serviços adicionais aos serviços de
SORs, principalmente
Estes adicionamentos levaram ao chamado middleware

43. SOD, SOR e Middleware (cont.)
Sistema Descrição Principal objetivo
SOD SO fortemente acoplado para multi-
processadores e multicomputadores
homogêneos
Esconder e gerenciar
recursos de hardware
SOR SO fracamente acoplado para
multicomputadores heterogêneos
(LAN/WAN)
Oferecer serviços locais
para clientes remotos
Middleware Camada adicional sobre um SOR Prover transparência de
distribuição

44. Sistemas Operacionais Distribuídos
SODs

45. Relembrando sistema operacional uni-processador
Aplicações compartilham recursos e por isso precisam ser
protegidas umas das outras
Ex: sejam aplicações A e B executando ao mesmo tempo, A não pode alterar os
dados de B simplesmente acessando a parte da memória onde os dados estão
armazenados – conceito de espaço de endereçamento
Aplicações têm que usar apenas facilidades oferecidas pelo SO
Ex: uma aplicação não pode copiar mensagens diretamente para uma interface
de rede. Em vez disso, o SO oferece primitivas de comunicação

46. Tipos de SODs
Sistema operacional multi-processador
Gerencia recursos de um multiprocessador
Sistema operacional multi-computador
Para multicomputadores homogêneos
A funcionalidade de SODs é essencialmente a mesma
de SOs tradicionais/convencionais, exceto que SODs
manipulam múltiplas CPUs

47. SO Multi-processador
Objetivo: alto desempenho através de múltiplos
processadores – o número de CPUs deve ser transparente
para a aplicação
Suporte a múltiplos processadores com acesso a uma
memória compartilhada
Proteção contra acesso concorrente para garantir
consistência, através de primitivas de sincronização
Semáforo
Monitor

48. SO Multi-computador
Não há compartilhamento de memória, mas sim comunicação –
comunicação confiável é um aspecto importante e complexo

49. Sistemas de memória distribuída compartilhada
Objetivo: emular memória
compartilhada em multi-
computadores
Exemplo
a) Páginas de espaço de endereçamento
distribuídas em 4 máquinas
b) Situação após CPU 1 fazer referência
à página 10
c) Situação se página 10 é read-only e
replicação é usada – cuidado:
“réplicas” desatualizadas podem
causar inconsistência

50. Sistemas Operacionais de Rede
SOR

51. Serviços
Em SORs, serviços estão disponíveis em máquinas distintas

52. Serviços (cont.)
Login remoto (rlogin)
Cópia remota (rcp)
É preciso saber onde (máquinas) os arquivos se localizam...
Pouca transparência!

53. Middleware

54. Ideal
Escalabilidade e abertura – SORs
Transparência e uso mais fácil – SODs

55. Estrutura

56. Serviços Agregados
Nomeação
Persistência
Transações
Segurança
....

57. Abertura

58. Conclusões
Sistemas homogêneos
Transparência de distribuição
Alto desempenho
Memória compartilhada
Controle de concorrência
Sistemas heterogêneos
Transparência de distribuição
e comunicação
Serviços
Abertura
Sistemas heterogêneos
Pouca transparência
Escalabilidade
Comunicação