Post on 29-Jul-2019
Prof. Luiz Fernando Bittencourt IC - UNICAMP
MC714 Sistemas Distribuídos 2° semestre, 2013
Prof. Luiz Fernando Bittencourt IC - UNICAMP
Arquiteturas
Prof. Luiz Fernando Bittencourt IC - UNICAMP
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.
Prof. Luiz Fernando Bittencourt IC - UNICAMP
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
Prof. Luiz Fernando Bittencourt IC - UNICAMP
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
Prof. Luiz Fernando Bittencourt IC - UNICAMP
Estilos arquitetônicos
Prof. Luiz Fernando Bittencourt IC - UNICAMP
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.
Prof. Luiz Fernando Bittencourt IC - UNICAMP
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.
Prof. Luiz Fernando Bittencourt IC - UNICAMP
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.
Prof. Luiz Fernando Bittencourt IC - UNICAMP
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.
Prof. Luiz Fernando Bittencourt IC - UNICAMP
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.
Prof. Luiz Fernando Bittencourt IC - UNICAMP
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.
Prof. Luiz Fernando Bittencourt IC - UNICAMP
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.
Prof. Luiz Fernando Bittencourt IC - UNICAMP
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.
Prof. Luiz Fernando Bittencourt IC - UNICAMP
Arquiteturas de sistema
Prof. Luiz Fernando Bittencourt IC - UNICAMP
Arquitetura de sistema • Onde são colocados os componentes de software.
• Centralizada, descentralizada, híbrida.
Prof. Luiz Fernando Bittencourt IC - UNICAMP
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.
Prof. Luiz Fernando Bittencourt IC - UNICAMP
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.
Prof. Luiz Fernando Bittencourt IC - UNICAMP
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.
Prof. Luiz Fernando Bittencourt IC - UNICAMP
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.
Prof. Luiz Fernando Bittencourt IC - UNICAMP
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.
Prof. Luiz Fernando Bittencourt IC - UNICAMP
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
Prof. Luiz Fernando Bittencourt IC - UNICAMP
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.
Prof. Luiz Fernando Bittencourt IC - UNICAMP
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.
Prof. Luiz Fernando Bittencourt IC - UNICAMP
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.
Prof. Luiz Fernando Bittencourt IC - UNICAMP
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).
Prof. Luiz Fernando Bittencourt IC - UNICAMP
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
Prof. Luiz Fernando Bittencourt IC - UNICAMP
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
Prof. Luiz Fernando Bittencourt IC - UNICAMP
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
Prof. Luiz Fernando Bittencourt IC - UNICAMP
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.
Prof. Luiz Fernando Bittencourt IC - UNICAMP
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.
Prof. Luiz Fernando Bittencourt IC - UNICAMP
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.
Prof. Luiz Fernando Bittencourt IC - UNICAMP
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.
Prof. Luiz Fernando Bittencourt IC - UNICAMP
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)
Prof. Luiz Fernando Bittencourt IC - UNICAMP
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
Prof. Luiz Fernando Bittencourt IC - UNICAMP
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?
Prof. Luiz Fernando Bittencourt IC - UNICAMP
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.
Prof. Luiz Fernando Bittencourt IC - UNICAMP
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
Prof. Luiz Fernando Bittencourt IC - UNICAMP
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
Prof. Luiz Fernando Bittencourt IC - UNICAMP
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.
Prof. Luiz Fernando Bittencourt IC - UNICAMP
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
Prof. Luiz Fernando Bittencourt IC - UNICAMP
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.
Prof. Luiz Fernando Bittencourt IC - UNICAMP
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
Prof. Luiz Fernando Bittencourt IC - UNICAMP
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.
Prof. Luiz Fernando Bittencourt IC - UNICAMP
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.
Prof. Luiz Fernando Bittencourt IC - UNICAMP
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.
Prof. Luiz Fernando Bittencourt IC - UNICAMP
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.
Prof. Luiz Fernando Bittencourt IC - UNICAMP
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|).
Prof. Luiz Fernando Bittencourt IC - UNICAMP
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.
Prof. Luiz Fernando Bittencourt IC - UNICAMP
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.
Prof. Luiz Fernando Bittencourt IC - UNICAMP
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.
Prof. Luiz Fernando Bittencourt IC - UNICAMP
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ó.
Prof. Luiz Fernando Bittencourt IC - UNICAMP
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
Prof. Luiz Fernando Bittencourt IC - UNICAMP
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.
Prof. Luiz Fernando Bittencourt IC - UNICAMP
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.
Prof. Luiz Fernando Bittencourt IC - UNICAMP
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.
Prof. Luiz Fernando Bittencourt IC - UNICAMP
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”.