mc714 - ic.unicamp.brbit/ensino/mc714_2s13/aulas/aula10.pdf · prof. luiz fernando bittencourt ic -...

Prof. Luiz Fernando Bittencourt IC - UNICAMP

MC714 Sistemas Distribuídos 2° semestre, 2013


Arquiteturas


Arquiteturas • Componentes de sistema distribuído espalhados por diversas máquinas.

• Controle demanda organização. • Organização lógica do software e organização física dos componentes.


Software • Componentes de software constituem o sistema. • Arquitetura de software

• Como vários componentes estão organizados • Como devem interagir

• Arquiteturas centralizadas, arquiteturas descentralizadas, arquiteturas híbridas

• Separar aplicações das plataformas subjacentes: middleware

• Várias técnicas para alcançar transparência, e que afetam o próprio middleware


Software – sistemas autonômicos • Também é possível conseguir adaptabilidade fazendo o sistema monitorar seu próprio comportamento.

• Sistemas autonômicos • Realimentação de informação


Estilos arquitetônicos


Estilos arquitetônicos • Organização lógica do sistema em componentes de software – arquitetura de software

• Estilo arquitetônico: componentes, modo como estão conectados, dados trocados, como são configurados para formar o sistema

• Componente: unidade modular com interfaces requeridas e fornecidas bem definidas; substituível.

• Conector: mecanismo que serve de mediador da comunicação entre componentes. •  Facilidades para chamadas de procedimento (remotas), passagem

de mensagem, fluxo de dados.


Estilos arquitetônicos • Várias configurações usando componentes e conectores.

• Arquitetura em camadas. • Arquiteturas baseadas em objetos. • Arquiteturas centradas em dados. • Arquiteturas baseadas em eventos.


Arquitetura em camadas • Um componente da camada Li tem permissão de chamar componentes na camada subjacente Li-1 , mas não o contrário.

• Adotado em redes. • Em geral requisições descem pela hierarquia, resultados sobem.

• Fig. 31.


Arquitetura baseada em objetos • Cada objeto, em essência, corresponde a um componente.

• Conexão através de chamada de procedimento remota.

• Se ajusta à arquitetura cliente-servidor. • Fig. 32.


Arquitetura centrada em dados • Processos se comunicam por um repositório comum.

• Em sistemas distribuídos, tão importante quanto camadas e objetos.

• Muitas aplicações se comunicam por escrita/leitura de arquivos compartilhados.

• Sistemas web possuem processos que se comunicam por meio de serviços de dados web.


Arquitetura baseada em eventos • Processos se comunicam por meio de propagação de eventos que podem transportar dados.

• Associado a sistemas publish/subscribe. • Processos publicam eventos; middleware transmite somente para assinantes.

• Processos fracamente acoplados; não precisam se referir explicitamente uns aos outros.

• Fig. 33.


Arquitetura baseada em eventos • Pode ser combinada com arquiteturas centradas em dados, resultando em espaços compartilhados de dados. •  Processos desacoplados no tempo: não precisam ambos estarem

ativos para realizar comunicação.


Arquiteturas de software • Visam obter nível razoável de transparência de distribuição.

• Compromisso entre desempenho, tolerância a falha, facilidade de programação. •  Dependente de requisitos/aplicações: não há um sistema para

cobrir tudo.


Arquiteturas de sistema


Arquitetura de sistema • Onde são colocados os componentes de software.

• Centralizada, descentralizada, híbrida.


Arquitetura centralizada • Processos divididos em dois grupos: clientes e servidores.

• Servidor implementa um serviço específico. • Cliente requisita um serviço enviando uma requisição e aguarda resposta.

• Clientes requisitam serviços de servidores. • Comportamento de requisição-resposta. • Fig. 34.


Arquitetura centralizada • Cliente-servidor pode ser implementado por meio de um protocolo simples de comunicação se rede é confiável.

• Empacota mensagem identificando serviço desejado junto com dados necessários.

• Mensagem é enviada; servidor aguarda requisição, processa e empacota resultados em uma mensagem de resposta.


Arquitetura centralizada • Aplicação: protocolo de comunicação. • Confiabilidade versus eficiência; sem conexão, com conexão; retransmissão. •  Depende da aplicação.

• Retransmissão de mensagem: transfira R$1.000 da minha conta.

• Retransmissão de mensagem: qual o saldo da minha conta? •  Operação repetida sem danos: idempotente.

• Diversas maneiras de tratar falhas, dependendo do tipo de mensagem perdida.


Arquitetura centralizada • Muitos sistemas utilizam protocolos confiáveis orientados

à conexão. •  TCP/IP.

• Primeiro estabelece conexão, depois envia requisição. • Servidor pode usar a mesma conexão para enviar

resposta. • Conexão pode ser caro.

•  Estabelecer e encerrar conexão pode ocupar maior parte do tempo, principalmente se mensagens de requisição e resposta são pequenas.


Camadas de aplicação • Cliente-servidor: quem é quem? • Ex: banco de dados recebe consultas, mas somente realiza requisições a sistemas de arquivos que implementam as tabelas. •  Banco de dados apenas faz consultas.

• Muitas aplicações cliente-servidor visam dar suporte aos usuários de bancos de dados: três níveis. •  1. Interface de usuário – interação. •  2. Nível de processamento – aplicação. •  3. Nível de dados – gerência dos dados.


Camadas de aplicação •  Interface:

•  Tela baseada em caracteres (terminal). • X-windows.

• Processamento: •  Busca web: palavra chave, ordenar resultados, fazer consultas aos

bancos de dados. •  Análise de dados financeiros: estatística + IA.

• Dados •  Dados persistentes. •  Geralmente no lado do servidor. •  Manter consistência de dados (triggers). •  Muito comum ser banco de dados relacional.

•  Fig 35.a


Arquiteturas multidivididas • 3 níveis lógicos: várias possibilidades para distribuição física de uma aplicação no modelo cliente-servidor.

• Mais simples: •  2 tipos de máquinas: cliente com interface e servidor com

processamento e dados. •  Cliente é “terminal burro”.

• Arquitetura de 2 divisões. •  Fig. 35.b • Outras possibilidades.


Arquiteturas multidivididas • Tendência a retirar processamento e armazenamento do cliente. •  Mais problemáticas para gerenciar/atualizar. •  Mais software no cliente = mais propenso a erros.

• Clientes gordos / clientes magros. • Clientes magros: não precisamos mais de sistemas

distribuídos? •  SD muda para o lado do servidor.

• Arquiteturas de 3 divisões (em termos físicos). •  Servidor web repassa requisição para servidor da aplicação

(processamento), consulta BD.

•  Fig 36.


Arquiteturas descentralizadas • Arquiteturas multidivididas: conseqüência da divisão de

aplicação em interface/processamento/dados. • Em muitos ambientes, organização de aplicações cliente-

servidor é feita em arquiteturas multidivididas: distribuição vertical. •  Componentes logicamente diferentes em máquinas diferentes. •  Relação com fragmentação vertical: tabelas de BD subdivididas

em colunas e distribuídas. •  Divisão lógica e física: cada máquina executa grupo específico de

funções • Distribuição horizontal

•  Servidor/cliente divididos em partes logicamente equivalentes. •  Cada parte operando sobre seu próprio conjunto de dados. •  Distribuição de carga.


Arquiteturas descentralizadas • Peer-to-peer (P2P): distribuição horizontal. • Não há servidor sempre ligado. • Sistemas finais comunicam-se diretamente. • Peers intermitentemente conectados e mudam de

endereço. • Ex: distribuição de arquivos (bitTorrent), streaming

(KanKan), VoIP (Skype).


Cliente servidor versus P2P • Quanto tempo para distribuir arquivo de tamanho F para

N clientes: cliente-servidor versus P2P. •  Fig. 37. • Cliente-servidor: envia sequencialmente N cópias.

•  Servidor: •  tempo para enviar 1 cópia: F/us •  tempo para enviar N cópias: NF/us

•  Cliente: cada cliente faz o download •  dmin = taxa de download mínima entre os clientes. •  Tempo de download do cliente mais lento: F/dmin

Tempo para distribuir F para N clientes usando

cliente-servidor Dc-s > max{NF/us,,F/dmin}

Aumenta linearmente em N


Cliente servidor versus P2P • P2P:

•  Servidor: upload de pelo menos uma cópia – tempo F/us •  Cliente: cada cliente faz o download de uma cópia

•  Tempo de download do cliente mais lento: F/dmin

•  Clientes: download agregado de NF bits •  Taxa máxima de upload: us + Σui

Tempo para distribuir F para N clientes usando

P2P DP2P > max{F/us,,F/dmin,,NF/(us + Σui)}

Aumentam linearmente em N


Cliente servidor versus P2P • Upload cliente = u, F/u = 1 hora, us = 10u, dmin ≥ us

0

0.5

1

1.5

2

2.5

3

3.5

0 5 10 15 20 25 30 35

N

Min

imum

Dis

tribu

tion

Tim

e P2PClient-Server


Arquiteturas descentralizadas • Peer-to-peer (P2P): distribuição horizontal. • Processos que constituem o sistema são todos iguais.

•  Funções necessárias são executadas por todos. •  Interação simétrica: cliente e servidor ao mesmo tempo.

• Como organizar os peers? Rede de sobreposição (overlay). •  Nós são processos; enlaces são canais de comunicação lógicos. •  Em geral, processo não pode se comunicar diretamente com outro

processo arbitrário: deve obedecer overlay. •  Redes de sobreposição: estruturadas e não estruturadas.


Arquiteturas descentralizadas • Arquiteturas P2P estruturadas:

•  Rede de sobreposição é construída com a utilização de um procedimento determinístico.

•  Mais utilizado: tabela hash distribuída (distributed hash table – DHT).

•  Ex.: Chord, CAN, Pastry, Tapestry

• Arquiteturas P2P não estruturadas: •  Algoritmos aleatorizados para construir a rede de sobreposição. •  Idéia é que cada nó mantenha lista de vizinhos, mas que essa lista

seja construída de modo que envolva alguma aleatorização. •  Localização de item pode depender de inundação da rede.


Arquiteturas P2P estruturadas • Rede de sobreposição construída com procedimento

determinístico. • Mais comum: Distributed Hash Table (DHT) •  Itens de dados recebem identificador (128, 160 bits...). • Nós do sistema também recebem identificador, no mesmo

espaço de identificadores. • Ponto crucial: implementar um esquema eficiente e

determinístico de mapeamento de chaves para identificadores de nós.

• Consulta a um item deve retornar o endereço do nó responsável pelo item.


Arquiteturas P2P estruturadas • Como atribuir chaves aos peers? •  Idéia básica:

•  Converter cada chave em um inteiro. •  Atribuir inteiro a cada peer. •  Colocar par (chave, valor) no peer mais próximo à chave.

• Atribuir identificador inteiro para cada peer no intervalo [0,2n-1] para algum n. •  Cada identificador de nó tem n bits.

• Requer que cada chave esteja no mesmo intervalo. • Para obter chave, usar função hash.

•  Ex.: chave = hash (“Pink Floyd – Dark Side of the Moon”). •  Daí vem o nome de tabela hash distribuída.


Chord (Stoica et al., 2003) • Nós organizados logicamente em um anel - DHT circular. • Regra: atribuir chave ao peer com ID mais próximo. •  Item de dado com chave k mapeado em nó com menor

identificador id >= k. •  Denominado nó sucessor da chave k: suc(k).

• Consulta: Lookup(k) deve retornar endereço de suc(k). • Cada peer conhece sucessor e predecessor imediatos

em uma rede de sobreposição. •  Fig. 38. • Outras: CAN, Pastry, Tapestry, Kademlia, Ulysses, Koorde

(grafos de DeBruijn)


Chord (Stoica et al., 2003)

• O(N) mensagens na média para resolver consulta.

0001

0011

0100

0101

1010

1100

1111

Responsável pela chave 1110 ?

Eu

1110

1110

1110

1110

1110

1110


DHT Circular com atalhos

• Cada peer conhece sucessor, predecessor e atalhos. • Redução de 6 para 2 mensagens. • É possível desenhar atalhos para que existam O(log(n))

vizinhos, O(log(n)) mensagens em consultas.

1

3

4

5

8 10

12

15

Responsável pela chave 1110?


Peer churn • Peers entram e saem da rede (churn). • Cada peer conhece seus dois sucessores. • Cada peer “pinga” seus dois sucessores para verificar se

continuam online. • Se o sucessor imediato sai, realoca segundo sucessor

como imediato.


Peer churn •  Peer 5 sai. •  Peer 4 transforma 8 em seu sucessor imediato e pergunta ao 8 qual

é seu sucessor. •  Peer 4 torna sucessor de 8 (10) seu segundo sucessor.

1

3

4

5

8 10

12

15


Peer churn •  Peer 13 quer entrar: gera um identificador (aleatório) id. •  Consulta algum nó qual ponto da rede deve entrar: quem será seu

sucessor e predecessor. •  Transferência das responsabilidades de dados de 15 para 13.

1

3

4 13

8 10

12

15


CAN – Content Addressable Network • Espaço de coordenadas cartesianas de d dimensões

particionado entre os nós. •  Fig 48. • Espaço bidimensional [0,1]x[0,1] dividido entre 6 nós. • Cada nó tem uma região associada. • Cada item de dados em CAN é atribuído um único ponto

desse espaço, vinculando um nó responsável pelo dado.


CAN – Content Addressable Network • Entrada de um nó P em CAN:

•  Escolhe ponto arbitrário no espaço de coordenadas; •  Pesquisa o nó Q “dono” daquela região (utilizando roteamento

baseado em posicionamento); •  Nó Q subdivide sua região em duas metades e atribui metade a P;

• Nós monitoram seus vizinhos, responsáveis por regiões adjacentes.

• Na subdivisão, P sabe quem são seus vizinhos perguntado a Q.

•  Itens de dados são transferidos de Q para P. •  Fig. 49


CAN – Content Addressable Network • Saída de nó de CAN:

•  Saída do nó (0,6; 0,7). •  Região é designada a um de seus vizinhos, por exemplo (0,9; 0,9). •  Vizinho escolhido toma conta da região do nó que saiu. •  Torna repartição menos simétrica: repartição do espaço inteiro por

um processo de fundo.


Redes P2P não estruturadas • Dependem, em grande parte, de algoritmos aleatórios para construir overlay.

•  Idéia: cada nó tem uma lista de vizinhos construída de modo (mais ou menos) aleatório.

•  Itens podem ser colocados aleatoriamente nos nós – Balls and bins.

• Encontrar item = inundar a rede com consulta de busca.

• Rede parecida com grafo aleatório. • Ex.: Gnutella, Freenet


Redes P2P não estruturadas • Cada nó mantém uma lista de vizinhos vivos (visão parcial).

• Nós podem trocar regularmente entradas de suas visões parciais.

• Pode-se usar 2 threads, uma de “modo ativo” (push) e uma de “modo passivo” (pull). •  Modo ativo: empurra entradas para peers vizinhos

selecionados. •  Modo passivo: aguarda nó enviar as entradas.

• Só ativo ou só passivo pode resultar em redes desconexas.

• É preciso também apagar entradas velhas.


Redes P2P não estruturadas • Pull ou push isoladamente podem resultar em redes desconectadas. •  Melhor que nós troquem entradas de suas visões parciais.

• Nó quer se juntar ao grupo: contata nó arbitrário, possivelmente de lista de nós bem conhecidos e com alta disponibilidade.

• Saída de nó, caso haja troca de visões parciais: nó sai sem informar qualquer nó. É removido das visões parciais dos seus vizinhos na próxima atualização.


Gerenciamento de topologia • Estruturado e não estruturado podem não ser estritamente independentes.

• Troca e seleção cuidadosa de entradas de visões parciais pode levar a topologias específicas.

• Adoção de abordagem de duas camadas. • Fig 50. Camada inferior: p2p não estruturado com troca de visões parciais.

• Camada superior: seleção adicional de entradas para gerar topologia desejada.


Gerenciamento de topologia • Por exemplo, camada superior: função de ordenação onde nós são ordenados de acordo com certo critério. •  Ordenar conjunto de nós em ordem crescente de distância em

relação a um determinado nó P. •  Nó P gradativamente montará uma lista de seus vizinhos mais

próximos, desde que a camada inferior continue enviando nós selecionados aleatoriamente.


Gerenciamento de topologia •  Jelasity e Babaoglu [2005]. • Grade lógica NxN, um nó em cada ponto. •  Lista de c vizinhos mais próximos por nó, onde distância

entre nó (a1,a2) e (b1,b2) é d1+d2, com di = min (N-|ai-bi|, |ai – bi|).


Redes P2P não estruturadas • Podem ser usadas funções de ordenação de diversas maneiras.

• Ex.: funções com captura de proximidade semântica de nós.

• Construção de redes semânticas de sobreposição. • Algoritmos de busca eficientes em P2P não

estruturados.


Superpeers • Busca em P2P não estruturado pode ser ineficiente e não escalável.

• Alternativa é usar superpares. • Nós especiais que mantém um índice de itens de dados e/ou agem como intermediários.

• Outras situações convém abandonar simetria de sistemas P2P. •  Rede colaborativa de entrega de conteúdo (Content Delivery

Network – CDN) - armazenamento de páginas por nós para permitir acesso rápido a páginas próximas.

•  Nó que coleta informações sobre nós das proximidades permite seleção de quem tem recursos suficientes para armazenar conteúdo acessado.


Superpeers • Superpares podem ser organizados em uma rede P2P à organização hierárquica.

• Fig. 39. • Par comum conectado a superpar. • Relação cliente-superpar fixa, em geral: conecta-se a um superpar e permanece até sair da rede. •  Superpares: longa vida com alta disponibilidade.

• Associação fixa pode não ser melhor abordagem •  Melhor cliente se ligar a um superpar com índices que sejam

próximos ao seu interesse. •  Garbacki et al. (2005) à nós associam-se preferencialmente a

superpares que retornam um resultado de consulta para o nó.


Superpeers • Novo problema: como selecionar nós para serem superpares.

• Estreita relação com eleição de líder em sistemas distribuídos.

• Exemplo: Skype/NAT


Arquiteturas híbridas • Combina mais de um tipo de arquitetura, por ex. cliente-servidor e P2P

• Exemplo: sistemas de servidor de borda •  “Borda da rede” – fronteira entre as redes corporativas e a Internet,

como fornecido por um provedor de serviço de Internet (ISP). •  Fig. 51. •  Servem conteúdo e otimizam distribuição de conteúdo e de

aplicação.

•  Também comum em sistemas distribuídos colaborativos. • Cliente-servidor utilizado para nós conectarem-se ao

sistema, depois utilizam esquema descentralizado.


Arquiteturas híbridas • Ex.: BitTorrent – sistema de download de arquivos.

• Fig. 40. • Transfere pedaços (chunks - 256kb) de arquivos até completar o arquivo.

•  Importante garantir colaboração. • Usuário acessa diretório global – sites web – referências aos arquivos torrent.


BitTorrent • Torrent contém informações sobre rastreador (tracker). •  Servidor que mantém lista de nós ativos que tem o arquivo

requisitado. •  Ativo = transferindo algum arquivo para outro nó.

• Peer entrando em um torrent: •  Não possui pedaços, mas obtém com o tempo. •  Recebe do rastreador lista de peers daquele torrent e se conecta a

alguns (vizinhos). •  Enquanto baixa, também faz upload. •  Pode trocar os peers com quem realiza transferências. •  Peer pode sair da rede assim que obtém arquivo inteiro.


BitTorrent • Requisição de pedaços:

•  Peers diferentes têm subconjuntos diferentes de pedaços. •  Periodicamente, usuário requisita lista de pedaços de seus

vizinhos. •  Em seguida, requisita pedaços faltantes de seus vizinhos – mais

raro primeiro.

• Enviando pedaços – “tit-for-tat” •  Usuário envia pedaços a vizinhos que estão enviando a ele com a

maior taxa. •  Outros peers param de receber dados desse usuário. •  Re-avalia os “top 4” a cada 10 segundos.

•  A cada 30 segundos seleciona aleatoriamente outro peer e começa a enviar pedaços. •  “Desafoga” de forma otimista esse peer. •  Novo peer pode se juntar ao “top 4”.

mc714 - ic.unicamp.brbit/ensino/mc714_2s13/aulas/aula10.pdf · prof. luiz fernando bittencourt ic -...

Documents