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

Prof. Luiz Fernando Bittencourt IC - UNICAMP

MC714 Sistemas Distribuídos 2° semestre, 2013


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.


•  Tanenbaum & Van Steen, Distributed Systems: Principles and Paradigms, 2e, (c) 2007 Prentice-Hall, Inc. All rights reserved. 0-13-239227-5

Redes P2P não estruturadas


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

•  Tanenbaum & Van Steen, Distributed Systems: Principles and Paradigms, 2e, (c) 2007 Prentice-Hall, Inc. All rights reserved. 0-13-239227-5


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. •  Não há modo determinístico de rotear requisições: inundação.

• Alternativa é usar superpares. • Nós especiais que mantém um índice de itens de dados

e/ou agem como intermediários


Superpeers • Há outras situações em que 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.

• Nós como os que mantêm um índice, ou agem como intermediários, em geral são denominados super-pares (superpeers).


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 • Combinam 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”.


BitTorrent • Versões atuais suportam DHTs

•  Mainline DHT – baseado em Kademlia •  rede “sem” trackers (ou com tracker distribuído).


Arquiteturas versus Middleware


Arquiteturas versus Middleware • Middleware é uma camada entre aplicações e

plataformas distribuídas. •  Proporcionar transparência de distribuição: ocultar das aplicações,

até certo ponto, a distribuição de dados, processamento e controle.

• Sistemas de middleware, na prática, adotam estilo arquitetônico específico. •  CORBA – objetos •  TIB/Rendezvous – eventos

• Simplifica o projeto de aplicações. • Por outro lado, pode não ser o ideal para determinada

aplicação.


Arquiteturas versus Middleware • CORBA oferecia somente objetos que podiam ser

invocados por clientes remotos. •  Muito restritivo. •  Foram adotados outros padrões de interação, como mensagens.

• Acrescentar características pode resultar em soluções inchadas. •  Melhor ter soluções específicas adaptáveis a requisitos das

aplicações.


Arquiteturas versus Middleware • Middlewares simples de configurar, adaptar e

personalizar conforme necessidade da aplicação são desejáveis. •  Sistemas atuais com separação mais estrita entre políticas e

mecanismos. •  Vários mecanismos com os quais pode-se modificar

comportamento do middleware


Interceptadores •  Interceptadores: pedaço de software que interrompe o

fluxo de controle usual e permite que outro código seja executado.

•  Idéia básica de invocação remota em SDs com objetos: •  Objeto A pode chamar método de um objeto B quando este está

em uma máquina diferente de A. •  Objeto A enxerga interface local que é a mesma oferecida por B;

objeto A chama essa interface local. •  Chamada por A é transformada em invocação a objeto genérico

através de uma interface geral de invocação oferecida pelo middleware.

•  Invocação do objeto genérico é transformada em mensagem, que é enviada pela interface de rede do sistema local de A.

•  Fig. 52.


Interceptadores • Chamada B.faz_alguma_coisa(valor) é transformada em

uma chamada genérica invoke(B, &faz_alguma_coisa, valor).

• Se B for replicado, interceptação pode ajudar •  Interceptador de nível de requisição. •  Interceptador chama invoke para cada uma das réplicas. •  A não precisa estar ciente da replicação de B. •  Middleware não precisa de componentes para tratar da chamada

replicada. •  Apenas o interceptador de nível de requisição, que pode ser

adicionado ao middleware, precisa saber da replicação de B.


Interceptadores • Após invoke, uma chamada a objeto remoto deverá ser

enviada pela rede. •  Interface do sistema deve ser invocada para envio de mensagem. •  Interceptador de nível de mensagem pode ajudar na transferência

da invocação ao objeto visado. •  Ex.: valor é um conjunto grande de dados, melhor fragmentar. •  Middleware não precisa estar ciente da fragmentação.


Software adaptativo •  Interceptadores são na verdade um meio de adaptar o

middleware. •  ambiente dinâmico (mobilidade, variância no QoS, problemas de

hardware, bateria) à necessidade de adaptação. •  Peso da adaptação colocado no middleware ao invés de em toda

aplicação.

• Software adaptativo no middleware para tratar influências do ambiente. •  Menos sucesso que o esperado. •  Entretanto, considerado um aspecto importante em SDs

modernos.


Software adaptativo •  Três técnicas para adaptação de software:

•  Separação de interesses. •  Reflexão computacional. •  Projeto baseado em componente.


Software adaptativo • Separação de interesses:

•  Modo tradicional de modularizar: separar partes que implementam funcionalidade das que cuidam de outras coisas (funcionalidades extras – confiabilidade, desempenho, segurança, etc.

•  Middleware é em grande parte um manipulador de funcionalidades extras.

• Problema: não é fácil separar essas funcionalidades por meio de modularização. •  Segurança em módulo separado não funciona. •  Como isolar tolerância a falhas em serviço independente? •  Software orientado a aspecto: separar e entrelaçar esses

interesses cruzados em um sistema distribuído.


Software adaptativo • Reflexão computacional:

•  Capacidade de um programa inspecionar a si mesmo e, se necessário, adaptar seu comportamento.

•  Embutida em linguagens de programação.

• Alguns middlewares oferecem meios para aplicar técnicas reflexivas.

• Assim como orientação a aspecto, ainda não é largamente implantado em sistemas distribuídos.


Software adaptativo • Projeto baseado em componentes:

•  Permite que sistema seja configurado de forma estática ou em tempo de execução.

•  Configuração dinâmica requer suporte a ligação tardia.

• Permite selecionar automaticamente melhor implementação de um componente em tempo de execução.

• Ainda complexo para sistemas distribuídos. •  Substituição de um componente implica saber que efeito terá

sobre outros componentes distribuídos.


Software adaptativo • Busca continua por software adaptativo em SDs: não há

método ou implementação amplamente aceita. • Argumento para suportar software adaptativo em

sistemas distribuídos: muitos SDs não podem ser desligados. •  SDs devem ser capazes de reagir a mudanças em seu ambiente,

como trocar dinamicamente políticas de alocação de recursos.


Autogerenciamento em Sistemas Distribuídos


Autogerenciamento em SDs • Para suportar maior quantidade de aplicações, SDs

devem blindá-las aspectos indesejáveis das redes. • Necessidade de adaptação do comportamento (não de

seus componentes) de SDs em tempo de execução. • Organização dos componentes:

•  Fazer monitoração. •  Ajustes automáticos. •  Decidir onde são executados processos que manipulam a

adaptação.

• Computação autonômica (ou sistemas auto): sistemas de realimentação de controle de alto nível que permitam adaptação automática a mudanças.


Autogerenciamento em SDs • Sistemas auto:

•  Auto-gerenciador •  Auto-reparador •  Auto-configurador •  Auto-otimizador

• Auto-gerenciador: termo genérico para englobar suas variantes.


Realimentação de controle • Existem diversas visões de sistemas auto-gerenciadores. • Em comum: adaptação ocorre através de um ou mais

laços de realimentação de controle. •  Fig. 53. • Núcleo: componentes a serem gerenciados.

•  Guiados por parâmetros de entrada que podem ser controlados. •  Porém, podem também ser influenciados por perturbações ou

ruídos, i. e., entradas não controláveis. •  Perturbações: frequentemente advindas do ambiente do SD, mas

podem vir de interações não previstas de componentes.


Realimentação de controle •  Três elementos que formam o laço de realimentação de

controle. •  1. O sistema a ser monitorado

•  Vários aspectos do sistema precisam ser medidos. •  Dados: medição e estimação. Medição pode ser difícil ou pode

acarretar interferência na própria medição (p.ex. princípio da incerteza de Heisenberg / Gato de Schrödinger).

•  2. Componente de análise de realimentação •  Analisa medições e as compara com valores de referência. •  Algoritmos que decidem possíveis adaptações.

•  3. Mecanismos para influenciar o comportamento do sistema. •  Colocação de réplicas, mudança de prioridade de escalonamento,

troca dinâmica de serviços, movimentação de dados, redirecionamento, etc.

•  Acionados pelo componente de análise (este, ciente dos mecanismos e seus efeitos).


Realimentação de controle • Obs: laço de realimentação de controle também se ajusta

ao gerenciamento manual. •  Diferença é, justamente, a automatização do componente de

análise.

• De uma forma ou outra, precisa-se de monitoração decente, assim como mecanismos decentes para controlar comportamento do sistema.

• Algoritmos para análise dos dados e ações corretas são dificuldade no desenvolvimento de sistemas auto-gerenciadores.

• Organização lógica (Fig. 53) pode ser diferente da organização física. •  Componente de análise pode ser distribuído, por exemplo. •  Monitoração em cada máquina.


Resumo


Resumo • Arquitetura de software e arquitetura de sistema

•  Organização lógica •  Organização física

• Estilo arquitetônico (software) •  Princípio básico que é seguido na organização da interação entre

os componentes •  Camadas, orientação a objetos, orientação a eventos, orientação a

espaço de dados

• Organização física •  Cliente-servidor: certo grau de centralização. •  Arquiteturas descentralizadas: P2P/rede de sobreposição

estruturada ou não estruturada. •  Sistemas auto-gerenciadores: até certo ponto fundem idéias de

arquitetura de sistema e software. Laços de realimentação e controle e ajuste automático do comportamento.

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

Documents