Transcript Arquiteturas Descentralizadas e Híbridas. Arquitetura x

Sistemas Distribuídos
Jorge Surian
[email protected]
Sistemas Distribuídos: Arquiteturas Descentralizadas e Híbridas. Arquitetura x
Middleware.
Arquitetura de Sistema
 Arquiteturas Descentralizadas
– Cliente-servidor possuem duas distribuições:
» Distribuição vertical:
• Componentes logicamente diferentes em
máquinas diferentes
• Cada máquina é projetada para um grupo
específico de funções
» Distribuição horizontal:
• Cliente ou servidor pode ser fisicamente
subdividido em partes logicamente equivalentes
• Porção própria de dados
2
2
Arquitetura de Sistema
 Arquiteturas Descentralizadas Peer-to-Peer
– Processos são todos iguais.
– Grande parte da interação entre processos
é simétrica.
– Cada processo age como cliente e servidor ao
mesmo tempo (servente).
– Formada por um conjunto de nós, organizados em um
overlay ou rede de sobreposição.
» Overlay: rede na qual os nós são os processos e os enlaces
representam os canais de comunicação possíveis.
– Comunicação não pode ser feita diretamente.
– Arquiteturas estruturadas ou não-estruturadas.
3
3
Arquitetura de Sistema
 Arquiteturas Descentralizadas Peer-to-Peer
Estruturada
– Rede de sobreposição e construída com a utilização
de um procedimento determinístico.
– Tabela de hash distribuida (Distributed Hash Table DHT).
– Ponto crucial: implementar um esquema eficiente e
determinístico que mapeie a chave de um dado para
o identificador de um nó.
4
4
Arquitetura de Sistema
 Arquiteturas Descentralizadas Peer-to-Peer
Estruturada
– Ao consultar um determinado item de dado, o
endereço de rede do nó com o conteúdo é retornado.
– Requisição é roteada entre os nós até que o nó com o
dado requisitado seja alcançado.
– Dados e nós recebem uma chave aleatória.
5
5
Arquitetura de Sistema
 Arquiteturas Descentralizadas Peer-to-Peer
Estruturadas Gerais
– Quando o nó entra na rede, este recebe um espaço
do conjunto dos índices dos arquivos, ao sair da rede
a mesma deverá designar estes índices para outro
nó. As buscas não são difundidas na rede sem
direção como no flooding, ao invés disto são
direcionadas para o nó correto.
– Os protocolos que implementam este tipo de
arquitetura são bem mais complexos, existem poucos
estudos sobre utilização dos mesmos.
6
6
Arquitetura de Sistema
 Arquiteturas Descentralizadas Peer-to-Peer
Estruturadas Chord
– Nós estão logicamente organizados em um anel.
– Item de dado com chave k e mapeado para o nó com
o menor identificador id >= k → sucessor de k.
– No é denominado sucessor da chave k.
– Função LOOKUP(k), que retorna o endereço de rede
succ(k)
7
7
Arquitetura de Sistema
 Arquiteturas Descentralizadas Peer-to-Peer
Estruturadas Gerais
– Gerenciamento de associação ao grupo
» Ao entrar no sistema, o nó recebe um identificador aleatório id.
» Mas, como encontrar a posição no anel?
• Pesquisa em id retorna o endereço de rede
succ(id).
• Novo no contata succ(id) e seu predecessor e
se insere no anel.
• Na partida, o no envia os dados para o succ(id).
8
8
Arquitetura de Sistema
 Arquiteturas Descentralizadas Peer-to-Peer
Estruturadas Gerais
Esta arquitetura possui uma característica totalmente
descentralizada. Enquanto que nos sistemas com
flooding, cada peer é responsável pelo espaço do
índice dos arquivos que ele próprio contêm. Nessa
arquitetura esse conceito é distinto, pois cada nó é
responsável por um subconjunto do espaço de
índices.
9
9
Arquitetura de Sistema
 Arquitetura Descentralizada Chord
– O protocolo Chord é baseado no mecanismo de DHT
- Distributed Hash Table. Esse protocolo consiste na
utilização de chaves para mapear, localizar e remover
nodos em uma rede P2P.
– Seu funcionamento consiste em mapear os peers
conectados a rede através de um código hash que
identifica cada elemento. Com esse código, cada peer
pode localizar e identificar seus vizinhos através de
um emaranhado de peers conectados. A maneira
como isso é feita consiste em uma única operação
(lookup) que mapeia o endereço IP com o hash
gerado.
10
10
Arquitetura de Sistema
 Arquitetura Descentralizada Chord
– Os DHTs são em geral confundidos com os conceitos
de hash usadas nos bancos de dados, mas se
diferenciam das tabelas tradicionais em hash nos
seguintes aspectos:
» Devem suportar a inserção e remoção de nós, pois será necessário
atualizar o novo mapeamento dos nós.
» Outra questão é a necessidade de um protocolo de roteamento
para que o mapeamento possa ser feito constantemente.
11
11
Arquitetura de Sistema
 Arquitetura Descentralizada Chord
– No caso do Chord, o protocolo de roteamento seria
descartado para dar lugar ao consistent hashing.
– Esse mecanismo mantem o mapeamento das chaves
e nodos responsáveis por essas chaves. Com isso,
torna-se desnecessário o conhecimento de todos os
nós da rede por cada peer. Com isso,a escalabilidade
da rede aumenta consideravelmente.
– O funcionamento do Chord é fundamentado nas
tabelas auxiliares, como será visto mais
detalhadamente no futuro. No momento, basta
sabermos...
12
12
Arquitetura de Sistema
 Arquitetura Descentralizada Chord
13
13
Arquitetura de Sistema
 Arquiteturas Descentralizadas Peer-to-Peer
Estruturadas
– Exemplos: Napster
» É uma rede peer-to-peer com uma arquitetura tal que há um
servidor central ou um cluster de servidores que é responsável por
responder os pedidos de busca e realizar todas as tarefas de
manutenção da infraestrutura.
14
14
Arquitetura de Sistema
 Arquiteturas Descentralizadas Peer-to-Peer
Estruturadas
– Exemplos: Napster
» O Napster usava exatamente esse conceito. Sabemos que o
mesmo passou por problemas legais porque os seus usuários
utilizavam o serviço do Napster para compartilhar arquivos
protegidos por leis de direito autoral. Hoje, também sabemos que
os criadores do serviço foram processados e que a rede está fora
do ar, seus servidores estão impedidos de funcionar.
15
15
Arquitetura de Sistema
 Arquiteturas Descentralizadas Peer-to-Peer
Estruturadas
– Exemplos: Napster
» Essa situação ilustra o fato de redes desse tipo, onde existe um
ponto central, se este estiver inoperante, a rede não funciona.
Redes deste tipo não são verdadeiramente peer-to-peer, porque
além de existir um ponto único de falha, apenas a transferência de
arquivos é feita de forma distribuída. O mecanismo de buscas e a
manutenção da infraestrutura é realizada de forma centralizada,
conforme o paradigma cliente/servidor.
16
16
Arquitetura de Sistema
 Arquiteturas Descentralizadas Peer-to-Peer
Estruturadas
– Exemplos: Napster
» Como os mecanismos principais de uma rede de compartilhamento
de arquivos são os mecanismos de busca, que são centralizados
nesta arquitetura, sistemas deste tipo não nos trazem uma visão
abrangente de uma rede peer-to-peer.
17
17
Arquitetura de Sistema
 Arquiteturas Descentralizadas Peer-to-Peer
Estruturadas
– Exemplos: Napster
18
18
Arquitetura de Sistema
 Arquiteturas Descentralizadas Peer-to-Peer
Estruturadas
– Exemplos: Napster
» Antes do Napster havia alguns sites que disponibilizavam musicas
no formato MP3 porém quando havia alguma atualização do site
era difícil encontrar as músicas que se queriam pois a maioria dos
sites não possuíam muita capacidade de armazenamento, e por
isso os links que apontavam para algumas músicas já não serviam
pois o arquivo tinha sido substituído por outro. Outro problema era
que não se sabia quando um novo arquivo seria disponibilizado.
19
19
Arquitetura de Sistema
 Arquiteturas Descentralizadas Peer-to-Peer
Estruturadas
– Exemplos: Napster
» Como Napster esses problemas foram solucionados. Os link
provenientes de uma busca pela música desejada eram todos
funcionais. E qualquer atualização também era fornecida pela
busca. Os Servidores do Napster lidavam com a transferência dos
arquivos entre os clientes, porém não os armazenavam. O
protocolo de rede do Napster criava um acesso P2P entre seus
clientes. A simplicidade de uso que o P2P fornece fez com que o
Napster e outros sistemas que o utilizam tivessem enorme sucesso.
20
20
Arquitetura de Sistema
 Arquiteturas Descentralizadas Peer-to-Peer
Estruturadas
– Exemplos: Gnutella
» Esta arquitetura é caracterizada pela completa descentralização de
seu funcionamento. Os mecanismos de busca e manutenção da
infraestrutura estão distribuídos pela rede. Neste tipo de sistema,
cada nó é responsável por manter a listagem dos seus próprios
arquivos, e responder quando receber uma busca para um arquivo
que seja uma resposta válida para a busca em questão. Para isto, é
utilizado o mecanismo de "flooding".
21
21
Arquitetura de Sistema
 Arquiteturas Descentralizadas Peer-to-Peer
Estruturadas
– Exemplos: Gnutella
» A rede deste tipo mais conhecida e estudada é a rede Gnutella. O
protocolo utilizado é relativamente simples e provê um
entendimento de como uma rede peer-to-peer funciona. Este
trabalho contêm um estudo de caso da especificação completa do
protocolo Gnutella versão 0.4.
22
22
Arquitetura de Sistema
 Arquiteturas Descentralizadas Peer-to-Peer
Estruturadas
– Exemplos: Gnutella
» As redes deste tipo possuem uma limitação muito grande que está
ligado ao fato de seu mecanismo de busca utilizar o conceito de
flooding. Para que uma rede não fique saturada com a repetição
infinita do flooding de mensagens, estas mensagens possuem um
número máximo de nós que a mesma pode atravessar. Isto possui
uma séria implicação, mesmo que um arquivo exista no sistema e
que o peer que o contenha esteja on-line, uma busca para este
arquivo pode falhar.
23
23
Arquitetura de Sistema
 Arquiteturas Descentralizadas Peer-to-Peer
Estruturadas
– Exemplos: Gnutella
24
24
Arquitetura de Sistema
 Arquiteturas Descentralizadas Peer-to-Peer Não
Estruturadas
– Algoritmos aleatório são usados para construir a rede
de sobreposição.
» Cada nó mantém uma lista de vizinhos.
» Dados também são espalhados aleatoriamente.
» Como encontrar os dados?
–Inundar a rede com uma busca...
25
25
Arquitetura de Sistema
 Arquiteturas Descentralizadas Peer-to-Peer Não
Estruturadas
– Gerenciamento de associação ao grupo:
»
»
»
»
Grafo aleatório.
Cada no possui n vizinhos → visão parcial.
Nós trocam entradas regularmente de sua visão parcial.
Principal objetivo: atualizar saídas de nós, construir uma nova
vizinhança de forma dinâmica para alcançar uma característica em
específico.
» Nos trocam as listas de vizinhos em dois modos diferentes: pull
(puxar) ou push (empurrar)
» Protocolos que usam somente pull ou push →grafos não
conectados
26
26
Arquitetura de Sistema
 Arquiteturas Descentralizadas peer-to-peer:
Gerenciamento de Redes de Sobreposição
27
27
Arquitetura de Sistema
 Arquiteturas Descentralizadas peer-to-peer:
Superpares [superpeers]
– A medida que a rede cresce, localizar itens de dados
em sistemas P2P não estruturados pode ser
problemático.
– Nós que mantém o índice de dados ou que agem
como nos intermediários que possuem dados para
disponibilizar os recursos a nós vizinhos.
– Sempre que um no comum se junta a rede, se liga a
um dos superpares.
28
28
Arquitetura de Sistema
 Arquiteturas Híbridas
– Sistemas distribuídos nas quais soluções clientes-servidor são
combinadas com arquiteturas descentralizadas.
– Exemplo: Sistemas distribuídos colaborativos.
» Principal objetivo e iniciar a troca de informações.
» Após adição do no na rede, a distribuição dos dados e feita
de forma descentralizada.
» BitTorrent
29
29
Arquiteturas versus Middleware
 Sistemas de middleware seguem um estilo arquitetônico
especifico
– Muitos middlewares adotam sistema arquitetônico
baseado em objetos (CORBA,TIB/Rendezvous).
– Ideia principal: desenvolver sistemas de middleware
que sejam simples de configurar, adaptar e
personalizar conforme necessidade da aplicação.
» Solução: Interceptadores (trata-se de um software que
interromperá o fluxo de controle usual permitindo que seja
executado um código específico da aplicação.
30
30
Arquiteturas versus Middleware
 Software que interrompera o fluxo de controle usual e
permitira que seja executado um outro código.
– Exemplo:
• Objeto A chama um método do objeto B enquanto
esse residir numa máquina distinta de A.
• É oferecida ao objeto A uma interface local que é
exatamente a mesma oferecida pelo objeto B.
31
31
Arquiteturas versus Middleware
 Software que interrompera o fluxo de controle usual e
permitira que seja executado um outro código.
– Exemplo:
• A simplesmente chama o método disponível na
interface. Essa chamada original é transformada em
uma chamada genérica, possibilitada por meio de
uma interface geral de invocação de objeto oferecida
pelo middleware na máquina onde A reside.
• Finalmente, a invocação a objeto genérico é
transformada em uma mensagem que é enviada por
meio de uma interface de rede de nível de transporte
como oferecida pelo sistema operacional local de A.
32
32
Arquiteturas versus Middleware
 Interceptadores
 Se o objeto B é replicado, cada replica deveria ser explicitamente
invocada.
 Interceptor de nível de requisição: replicar as chamadas.
33
33
Autogerenciamento em Sistemas Distribuídos
 Sistemas Distribuídos precisam fornecer soluções gerais de
blindagem contra aspectos indesejáveis inerentes a redes.
 Objetivo: suportar o maior numero possível de aplicações.
 Solução: Sistemas Distribuídos adaptativos.
 Ideia: Construir sistemas onde seja possível fazer monitoração e
ajustes.
34
34
Fonte:
Tanenbaum, Andrew S. e Steen, Marteen Van. Sistemas Distribuídos, São
Paulo: Prentice Hall, 2008.
Copyright © 2010 Prof. Jorge Surian
Todos direitos reservados. Reprodução ou divulgação total ou parcial deste documento é
expressamente proíbido sem o consentimento formal, por escrito, do Professor Surian.
35
35