Embed Size (px)
Citation preview
1
INTRODUÇÃO AOS
SISTEMAS DISTRIBUÍDOS
Prof. Cesar Augusto Tacla http://www.dainf.ct.utfpr.edu.br/~tacla/EspSD/
UNIVERSIDADE TECNOLÓGICA FEDERAL DO PARANÁ
PR
2
Sumário
1. INTRODUÇÃO
a. Definição de sistemas distribuídos (SDs)
b. Exemplos de sistemas distribuídos
c. Tipos de aplicações distribuídas
d. Vantagens e dificuldades dos SDs
3
Sumário
Definição de sistemas distribuídos
1 a
4
Definição
◊ O que é um sistema distribuído?
Rede de
Comunicação
5
Definição
◊ Um sistema distribuído é uma coleção de computadores
autônomos conectados por uma rede de comunicação que
é percebida pelos usuários como um único computador
que provê um serviço ou resolve um problema.
◊ (Tanenbaum & Steen, 2002)
Esta definição faz referência a um conceito importante em sistemas distribuídos, o da transparência
6
Definição
◊ Um sistema distribuído é composto por computadores
conectados em rede (hardware e software) que se
comunicam e coordenam suas ações somente através do
envio de mensagens.
◊ (Coulouris et al., 2001)
7
Sumário
Exemplos de sistemas distribuídos
1 b
8
Exemplo 1: WEB
intranet
ISP
desktop computer:
backbone
satellite link
server:
%
network link:
%
%
%
Fonte: figura 1-1 (Coulouris et al., 2003) ISP: Internet Service Provider =
provedor de acesso
WEB: Acesso remoto a páginas
FTP: Transferência de arquivos
9
SISTEMA BANCÁRIO
10
Exemplo 2: Bancos
Caixas
automáticos
Caixas
automáticos BD banco 2 BKP BD banco 2
BKP BD banco 1 BD banco 1
BD = banco de dados
BKP = backup
Fonte: http://www.ida.liu.se/~TDDB37/lecture-notes/lect1.frm.pdf
11
◊ Aspectos importantes num sistema distribuído bancário:
• Acessos múltiplos (concorrentes) à mesma conta:
• vários usuários acessam a mesma conta ou um sistema do banco
(emissão de relatórios) acessa ao mesmo tempo em que usuários
realizam transações.
• Transações bancárias podem envolver contas armazenadas
em diferentes bancos de dados ou localidades.
12
• O serviço deve ser transparente ao usuário – não interessa
se os dados de sua conta estão armazenados no banco 1 ou
banco 2, a aplicação não deve em nenhum momento deixar
transparecer aspectos internos do sistema
• O serviço deve ser confiável (não deixa os objetos em
estados inconsistentes) e seguro
• Bases de dados replicadas devem ser consistentes. Bases
de dados replicadas: aumentam a tolerância a falhas, mas
podem tornar o sistema não confiável!
• Tolerância a falhas
13
NAPSTER E SIMILARES
14
Exemplo 3: Napster
Requisição de
MP3
Transferência de
arquivo
Servidor NAPSTER
usuário
usuário
usuário
usuário
Anúncio
15
Outros Exemplos
◊ Similares ao NAPSTER
EMULE
BITORRENT
SKYPE (VoIP)
MSN MESSENGER, YAHOO
◊ Outros
APLICAÇÕES DE MULTIMÍDIA
WEB conferência
Difusão de streams on-line (voz, vídeo)
16
CLUSTER
17
Exemplo 4: Cluster (1)
◊ CLUSTERS ou AGRUPAMENTOS
◊ Máquinas conectadas por rede de alta velocidade
◊ Necessidade de alto desempenho computacional
◊ Evitar custo de máquinas de alto desempenho
◊ Objetivo: compartilhar recursos computacionais
De processamento
De armazenamento
De memória
Outros
18
Exemplo 4: Cluster (2)
JAGUAR
Cluster de máquinas do Oak Ridge
National Laboratory (EUA)
Terceiro da lista dos TOP 500
SUPERCOMPUTERS
INSTALADO EM 2009
224.162 CORES
1.759.000 Gflops
FONTE http://www.top500.org
Solução: agrupamento físico de
máquinas de menor porte = cluster:
• mesmo espaço geográfico
• Normalmente dentro da mesma
organização, com software/hardware
homogêneos
Tianhe-2, a supercomputer developed
by China’s National University of
Defense Technology, retained its
position as the world’s No. 1 system with
a performance of 33.86 petaflop/s
(quadrillions of calculations per second)
3.120.000 cores 18/11/2013
19
Exemplo 4: cluster (3)
◊ Clusters são utilizados para...
◊ Aumentar a disponibilidade de serviço se um nodo falha, outro assume
◊ Equilibrar carga de trabalho um ou mais computadores do cluster atuam como distribuidores da
carga entre os demais
◊ Alto desempenho Para resolver tarefas complexas que podem ser decompostas em
sub-tarefas, cada uma rodando num nodo do cluster.
Google Donates One Billion Core-Hours to Science
20
GRID OU GRADE
21
Exemplo 5: Grid (1)
◊ GRID ou GRADE = as máquinas encontram-se distantes
geograficamente.
◊ É uma cooperativa de máquinas
não pertencem necessariamente a mesma organização!
são ditas organizações virtuais
não há administração central dos recursos computacionais
Utilização de protocolos/padrões abertos
Quando as máquinas não pertencem a uma organização, alguns
denominam esta forma de computação de computação
voluntária (volunteer computing)
22
Exemplo 5: Grid (2)
◊ Aplicações
Tarefas complexas decompostas
Reunião dos resultados parciais
Distribuição das tarefas pode ser feita em função de
disponibilidade dos recursos, capacidade, desempenho, custo e QoS
◊ Exemplos de grids de pesquisa
Laboratório Nacional de Computação Científica: http://lncc.br/
Campina Grande: http://ourgrid.org
23
Exemplo 5: Grid (3)
◊ Exemplos – participação de qualquer usuário final Primeiro projeto (1996): GIMPS MERSENNE PRIME SEARCH – busca
pelo maior número primo de Mersenne (matemático/monge francês) http://www.mersenne.org/
Definição: quando 2n-1 é um número primo ele é dito número primo de Mersenne.
World Community Grid:
http://www.worldcommunitygrid.org
Identificar quais defeitos em proteínas produzidas pelos genes humanos podem causar doenças
Utiliza BOINC
Xsede da universidade de Purdue
www.xsede.org
XSEDE - the Extreme Science and Engineering Digital Environment
24
◊ Continuação BBC Climate Change Experiment:
http://climateprediction.net/
Tentativa de prever o clima para o século 21
Utiliza BOINC
Introdução: http://www.gridcafe.org/EN/
25
CLUSTER X GRID
26
CLUSTER X GRID
◊ CLUSTER: conjunto de máquinas dedicadas
Tipicamente agrupadas em um único local físico de uma mesma
organização
◊ GRID: aproveitamento de recursos de máquinas ociosas
De uma organização
De voluntários (computação voluntária)
◊ Tanto clusters como grids necessitam de software para
gerenciamento de carga:
HTCondor – http://www.cs.wisc.edu/condor/
BOINC (grid) - http://boinc.berkeley.edu/
27
Softwares para gerenciamento de carga
JOB SUBMETIDO
PELO USUÁRIO
WORKLOAD MANAGEMENT
SOFTWARE
CLUSTER OU GRID
28
Responder as questões de 0010-TAR1-GridCluster-questoes.txt
http://www.dainf.ct.utfpr.edu.br/~tacla/EspSD/Aula1/0011-TAR1-GridCluster-questoes.txt
29
Sumário
Tipos de aplicações distribuídas
• resolução distribuída
• sistemas multiagentes
1 c
30
RESOLUÇÃO DISTRIBUÍDA
31
RESOLUÇÃO DISTRIBUÍDA
◊ Resolução distribuída de problemas
Um usuário deseja resolver um problema complexo (ex. renderização de
imagens complexas)
Decomposição de um problema em subproblemas pelo desenvolvedor de
modo top-down
Distribuição dos subproblemas para diferentes processos
Um dos processos coleta e monta o resultado final
T1
T1.1 T1.2 T1.3
32 Sistemas Distribuídos/UTFPR Prof. Cesar Augusto Tacla
RESOLUÇÃO DISTRIBUÍDA
33
RESOLUÇÃO DISTRIBUÍDA
Renderman da Pixar https://renderman.pixar.com/index.html
Filme 2 minutos 30 frames por segundo 7.200 minutos de renderização
No Distributed Render Environment (Grid da Universidade de Purdue):
Filme 2 minutos 30 frames por segundo 36 minutos de renderização
Fonte http://www.i-light.org/docs/IPgrid_fn_report.doc (TeraGrid Purdue)
Tempo
34
SISTEMAS MULTIAGENTES
35
SMA
◊ Sistemas multi-agentes
são sistemas abertos e heterogêneos onde
vários desenvolvedores desenvolvem agentes,
◊ Agentes
são software dotados de um certo grau de inteligência e,
principalmente, de interação com outros agentes, capazes de
interagirem e produzirem algum resultado útil ao usuário embora
não tenha sido concebidos inicialmente com aquele objetivo
específico.
◊ Fonte: http://www.pcs.usp.br/~jaime/papers/marietto_iberamia02_p.pdf
36
Exemplo integração de serviços
RECEBE
INTINERÁRIO
RESERVA
VEÍCULO
RESERVA HOTEL
RESERVA
PASSAGEM
Empresa XX
Hotel XX
Locação XX
Empresa YY
Hotel ZZ Hotel YY Hotel WW
Locação YY Locação ZZ
DEBITA CARTÃO
COMUNICA
CLIENTE
SERVIÇOS WEB
CLIENTE
Instituição Financeira
37
SMA
Em sistemas multiagentes, o foco na interação entre agentes
(competição ou colaboração); i.e. solução surge através da
interação
Ex. leilão, simulações sociais
Para simulações sociais, um bom início é a ferramenta de
simulação NETLOGO
Sistemas peer-to-peer são similares aos SMAs, há diferenças
conceituais nos modelos de arquiteturas.
SMA tem inspiração em
modelos psico-sociológicos e
cognitivos
Ex. arquitetura BDI
(Believes-Desires-Intentions)
38
PEER-TO-PEER
◊ P2P
As vezes, é citada como uma arquitetura, porém, conceitualmente
é mais do que isto!
Preconiza a igualdade entre os participantes – não há servidor, nem
cliente – todos são iguais. A rede é dos participantes.
Vide manifesto: http://www.realitysandwich.com/the_peer_peer_manifesto_the_emergence_p2p_civilization_and_political_economy
◊ Exemplo de sistemas
◊ GNUTELLA (precursor)
◊ SNEER (http://sneer.me/):
◊ computação soberana
39
Sumário
Vantagens e dificuldades dos SDs
1 d
40
Motivações
◊ Razões para construir um SD
Desempenho MAIOR DO QUE sistema centralizado
Distribuição natural das aplicações: bancárias, videoconf., etc.
Robustez: frente a falhas
Escalabilidade: sist. pode ser aumentado sem perda de
desempenho?
Compartilhamento de recursos
Impressoras e outros hardwares
Arquivos (inclusive páginas Web)
CPU
Memória
Espaço em disco
dados
41 Sistemas Distribuídos/UTFPR Prof. Cesar Augusto Tacla
Dificuldades
◊ O desenvolvimento de um sistema distribuído é mais
complexo do que um centralizado
HETEROGENEIDADE
ABERTOS
SEGUROS
ESCALÁVEIS
CONFIÁVEIS
CONCORRÊNCIA
TRANSPARÊNCIA
42
Exemplo
◊ Baseando-se no exemplo da aplicação bancária mostrada
no início destes slides e considerando que:
Há acessos múltiplos (concorrentes) à mesma conta;
Transações bancárias podem envolver contas armazenadas em
diferentes bancos de dados (BD);
Não interessa ao cliente se os dados de sua conta estão
armazenados no BD1 ou BD2
◊ pode-se concluir que as características importantes para
este tipo de sistema são... (> próximo)
43
Exemplo
◊ Acessos múltiplos (concorrentes) à mesma conta: vários usuários acessam a mesma conta ou um sistema do banco (emissão de relatórios) acessa ao mesmo tempo em que usuários realizam transações.
◊ Transações bancárias podem envolver contas armazenadas em diferentes bancos ou localidades.
◊ O serviço deve ser transparente ao usuário – não interessa se os dados de sua conta estão armazenados no banco de dados 1 ou 2, a aplicação não deve em nenhum momento deixar transparecer aspectos internos do sistema
◊ O serviço deve ser confiável e seguro
◊ Bases de dados replicadas devem ser consistentes (não apresentar dados conflitantes)
◊ Tolerância a falhas
44
HETEROGENEIDADE
◊ Lidar com diferentes
Redes
hardwares (computadores)
sistemas operacionais
Linguagens de programação
◊ Além de resolver os problemas de heterogeneidade, o middleware define um modelo
computacional uniforme para a programação de aplicações distribuídas.
HARDWARE HARDWARE
PROTOCOLOS
SIST. OPER.
PROTOCOLOS
SIST. OPER.
MIDDLEWARE MIDDLEWARE
APLICAÇÃO DISTRIBUÍDA APLICAÇÃO DISTRIBUÍDA
HARDWARE HARDWARE
PROTOCOLOS
SIST. OPER.
PROTOCOLOS
SIST. OPER. PLATAFORMA
RMI
RPC
CORBA
45
ABERTOS
◊ O grau de abertura de um SD depende de:
Facilidade de adicionar novos recursos
De hardware
De software: novos serviços ou re-implementação de antigos
SD abertos baseiam-se em:
Mecanismos de comunicação uniformes
Especificados por organismos tais como OMG e IETF
Ex. CORBA (OMG)
Publicação de interfaces de serviços: para esconder a
heterogeneidade de implementação dos serviços, as
implementações devem aderir a uma forma de publicar as
interfaces dos serviços
46
SEGURANÇA
◊ Segurança envolve: “selar” informações importantes enviadas através da rede (ex.
criptografia de número de cartão de crédito)
Identidade: garantir a autenticidade da fonte.
Ex. um médico deseja acessar dados de pacientes de forma remota. É preciso assegurar que o usuário é realmente o médico.
Ex. um usuário deseja comprar um livro pela Internet. É preciso assegurar a identidade da loja virtual - que realmente é uma loja e não vai fazer mal uso do cartão.
Problemas:
Indisponibilidade de serviço devido a ataques
Segurança de código móvel (ex. .exe anexados a emails, applets)
47
ESCALABILIDADE
◊ Um SD é escalável se, ao adicionarmos novos recursos
e/ou usuários, seu desempenho permanece satisfatório.
◊ Exemplos:
Endereços IPv4 de 32 bits => IPv6 128 bits
DNS, no início, era uma tabela => foi particionada e é tratada
localmente contendo replicações.
◊ Técnicas para garantir escalabilidade:
Replicação de dados
Caching
Replicação de serviços
48
Tratamento de falhas
◊ Falhas são normalmente parciais em SDs
Dificilmente todos os componentes falham simultaneamente
◊ Detecção
Mensagens corrompidas => checksum
Crash de um servidor => nunca é certo se o servidor caiu, se a falha
está no link ou se a rede está sobrecarregada
◊ Esconder falhas
Se uma mensagem não chega no destino => retransmissão
Dados podem ser escritos em dois discos, se um está danificado,
utiliza-se a cópia.
49
Tratamento de falhas (2)
◊ Tolerância a falhas
Exemplo: quando um navegador da Internet não consegue acessar
um servidor ele não prende o usuário indefinidamente.
◊ Como tornar um sistema tolerante a falhas?
Redundância pode tornar sistema tolerante a falhas
Replicação de dados
No serviço DNS cada entrada é replicada em pelo menos dois
servidores
Explorar rotas alternativas na Internet
Maior tolerância a falhas aumenta a disponibilidade do sistema
50
Transparência
◊ O sistema deve ser visto pelo usuário e pelo programador
como um todo e não como uma coleção de componentes
◊ Vários tipos de transparência
Acesso: recursos locais e remotos são acessados através de
operações idênticas
Localização: permite acessar um recurso sem conhecimento de sua
localização (ex. pela URL e não pelo IP)
Replicação: múltiplas instâncias de um recurso podem ser
utilizadas sem que isto seja explícito para usuários e
programadores
51
TRANSPARÊNCIA
◊ Vários tipos (cont)
Concorrência: vários processos
podem acessar o mesmo
recurso sem interferir na
utilização um do outro nem no
recurso.
Mobilidade: permite a
movimentação de recursos e
clientes dentro de um sistema
sem afetar a operação
Ex: sistema de telefonia
celular (emissor)
52
RESUMO
SISTEMAS DISTRIBUÍDOS SÃO ÚTEIS PARA
◊ Melhorar desempenho
◊ Melhor adaptados a distribuição natural dos elementos
◊ Porém são complexos
◊ são inerentemente concorrentes
◊ devem ser confiáveis
◊ devem ser transparentes
◊ funcionar em plataformas heterogêneas
◊ Middlewares resolvem parte destes problemas
