Sistemas Distribuídos Jorge Surian [email protected] Sistemas Distribuídos: Arquiteturas Descentralizadas e Híbridas. Arquitetura x Middleware

Sistemas DistribuídosJorge [email protected]

Sistemas Distribuídos: Arquiteturas Descentralizadas e Híbridas. Arquitetura x Middleware.

22

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

33


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.

44


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

55


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.

66


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.

77


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)

88


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

99


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.

1010


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.

1111


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.

1212


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

1313


Arquitetura Descentralizada Chord

1414


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.

1515



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

1616



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

1717



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

1818



1919



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

2020



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

2121


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

2222



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

2323



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

2424



2525


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

2626


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

2727


Arquiteturas Descentralizadas peer-to-peer: Gerenciamento de Redes de Sobreposição

2828


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.

2929


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

3030

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.

3131


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.

3232


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.

3333


Interceptadores

Se o objeto B é replicado, cada replica deveria ser explicitamente invocada.

Interceptor de nível de requisição: replicar as chamadas.

3434

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.

3535

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.

Fonte:

Tanenbaum, Andrew S. e Steen, Marteen Van. Sistemas Distribuídos, São Paulo: Prentice Hall, 2008.

Documents

Sistemas Distribuídos Jorge Surian [email protected] Sistemas Distribuídos: Arquiteturas Descentralizadas e Híbridas. Arquitetura x Middleware