Prof. Luiz Fernando Bittencourt MC714. Sistemas Distribuídos 2 semestre, 2013

Transcrição

1 MC714 Sistemas Distribuídos 2 semestre, 2013

2 Arquiteturas descentralizadas Arquiteturas multidivididas: conseqüência da divisão de aplicação em interface/processamento/dados. Em muitos ambientes, organização de aplicações clienteservidor é 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.

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

4 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/u s tempo para enviar N cópias: NF/u s Cliente: cada cliente faz o download d min = taxa de download mínima entre os clientes. Tempo de download do cliente mais lento: F/d min Aumenta linearmente em N Tempo para distribuir F para N clientes usando cliente-servidor D c-s > max{nf/u s,,f/d min }

5 Cliente servidor versus P2P P2P: Servidor: upload de pelo menos uma cópia tempo F/u s Cliente: cada cliente faz o download de uma cópia Tempo de download do cliente mais lento: F/d min Clientes: download agregado de NF bits Taxa máxima de upload: u s + Σu i Tempo para distribuir F para N clientes usando P2P D P2P > max{f/u s,,f/d min,,nf/(u s + Σu i)} Aumentam linearmente em N

6 Cliente servidor versus P2P Upload cliente = u, F/u = 1 hora, u s = 10u, d min u s Minimum Distribution Time P2P Client-Server N

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

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

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

10 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,2 n -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.

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

12 Chord (Stoica et al., 2003) Eu Responsável pela chave 1110? O(N) mensagens na média para resolver consulta. 1110

13 DHT Circular com atalhos Responsável pela chave 1110? 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. 5 4

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

15 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

16 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

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

18 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

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

20 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

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

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

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

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

27 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- aibi, ai bi ). Tanenbaum & Van Steen, Distributed Systems: Principles and Paradigms, 2e, (c) 2007 Prentice-Hall, Inc. All rights reserved

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

29 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

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

31 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: conectase 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ó.

32 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

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

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

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

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

37 BitTorrent Versões atuais suportam DHTs Mainline DHT baseado em Kademlia rede sem trackers (ou com tracker distribuído).

38 Arquiteturas versus Middleware

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

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

41 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

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

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

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

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

46 Software adaptativo Três técnicas para adaptação de software: Separação de interesses. Reflexão computacional. Projeto baseado em componente.

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

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

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

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

51 Autogerenciamento em Sistemas Distribuídos

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

53 Autogerenciamento em SDs Sistemas auto: Auto-gerenciador Auto-reparador Auto-configurador Auto-otimizador Auto-gerenciador: termo genérico para englobar suas variantes.

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

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

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

57 Resumo

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