estratégia de trabalho - departamento de ciência da ... · escondem absolutamente nada da...

1

Sistemas Distribuídos

Gustavo Reis

[email protected]

Comunicação Remota

2

- Comunicação Remota

Comunicação entre processos está no coração de todo sistema distribuído.

Não tem sentido estudar sistemas distribuídos sem examinar cuidadosamente os modos pelos quais processos em máquinas diferentes podem trocar informações.

A comunicação em sistemas distribuídos é sempre baseada em troca de mensagens de baixo nível como a oferecida pela rede subjacente.

Sistemas distribuídos modernos frequentemente consistem em milhares ou até milhões de processos espalhados por uma rede cuja comunicação não é confiável, como a Internet.

Existem três modelos de comunicação de ampla utilização:

Chamada de procedimento remoto (Remote Procedure Call - RPC)

Middleware orientado a mensagem (Message-Oriented Middleware - MOM)

Fluxo de dados.

3


Chamada de procedimento remoto

Muitos sistemas são baseados em troca explícita de mensagens entre processos.

Contudo, os procedimentos send e receive não escondem absolutamente nada da comunicação, o que é importante para obter transparência de acesso em sistemas distribuídos.

Proposta diferente de manipular comunicação por Birrell e Nelson (1984).

4



A sugestão é permitir que programas chamassem procedimentos localizados em outras máquinas.

Quando um processo na máquina A chama um procedimento na máquina B, o processo chamador A é suspenso, e a execução do procedimento chamado ocorre em B.

Informações podem ser transportadas do chamador para quem foi chamado nos parâmetros e podem voltar no resultado do procedimento (a semântica de uma chamada remota deve ser idêntica à de uma chamada local: passa parâmetros e retorna resultados).

5



6



O cliente que acessa um serviço inclui um procedimento stub para cada procedimento da interface de serviço.

A função de um procedimento stub é semelhante à de um método proxy. Ele se comporta como um procedimento local para o cliente, mas em vez de executar a chamada, ela empacota o identificador de procedimento e os argumentos em uma mensagem de requisição e a envia para o servidor por meio de seu módulo de comunicação.

7



Quando a mensagem de resposta chega, ela desempacota os resultados.

O processo servidor contém um despachante junto com um procedimento stub de servidor e um procedimento de serviço, para cada procedimento na interface de serviço.

O despachante seleciona um dos procedimentos stub de servidor, de acordo com o identificador de procedimento presente na mensagem de requisição.

8



Um procedimento stub de servidor é como um método esqueleto, pois ele desempacota os argumentos presentes na mensagem de requisição, chama o procedimento de serviço correspondente e empacota os valores de retorno para a mensagem de resposta.

Os procedimentos de serviço implementam os procedimentos da interface de serviço.

9


RMI Java

A RMI Java estende o modelo de objeto Java para dar suporte para objetos distribuídos na linguagem Java.

Em particular, ela permite que os objetos invoquem métodos em objetos remotos usando a mesma sintaxe das invocações locais.

Além disso, a verificação de tipo se aplica igualmente às invocações remotas e às locais.

Entretanto, um objeto que faz uma invocação remota sabe que seu destino é remoto, pois precisa tratar exceções RemoteException; e o implementador de um objeto remoto sabe que é remoto porque precisa implementar a interface Remote.

10


RMI Java

Interface remota

Messenger.java

11


RMI Java Implementação

da Interface

MessengerImpl.java

12


RMI Java Implementação da Interface

MessengerImpl.java

13



Cliente

ClientMessenger.java

14



Cliente

ClientMessenger.java

15


RMI Java

Passagem de parâmetros e resultados Na RMI Java, supõe-se que os parâmetros de um método são

parâmetros de entrada e o resultado de um método é um único parâmetro de saída.

Qualquer objeto que seja serializável – isto é, que implemente a interface Serializable – pode ser passado como argumento ou ser resultado na RMI Java.

Todos os tipos primitivos e objetos remotos são serializáveis. As classes de argumentos e valores de resultado são

carregadas por download no destino pelo sistema RMI, quando necessário.

16


RMI Java

Download de classes A linguagem Java é projetada para permitir que as

classes sejam carregadas por download de uma máquina virtual a outra.

Isso é particularmente relevante para objetos distribuídos que se comunicam por meio de invocação remota.

Se o destino ainda não possuir a classe de um objeto passado por valor, seu código será carregado por download automaticamente.

17


RMI Java

RMIregistry O RMIregistry é o vinculador da RMI Java. Uma instância de RMIregistry deve ser executada em cada

computador servidor que contenha objetos remotos. Ele mantém uma tabela mapeando nomes textuais no estilo

dos URLs, em referências para objetos remotos contidos nesse computador.

Ele é acessado por métodos da classe Naming, cujos métodos recebem como argumento uma string no formato como URL, na forma:

• //nomeComputador:porta/nomeObjeto

18


RMI Java

Classe Naming (servidor)

19


RMI Java

Classe Naming (cliente)

20


Comunicação orientada a mensagem

RPC e invocações de objeto remoto ocultam comunicação em sistemas distribuídos (transparência)

Mas quando não se pode garantir que o receptor esteja em execução no momento em que uma requisição é emitida, são necessários mecanismos alternativos de comunicação

No RPC a comunicação síncrona pode ser feita com o bloqueio do cliente até que suas requisições tenham sido processadas pelo receptor

21



Outra solução é a troca de mensagens

Permite o enfileiramento de mensagens mesmo ainda que as partes não estejam executando no momento em que a comunicação é iniciada

Comunicação assíncrona

22



Comunicação transiente orientada a mensagem Interface Berkeley: interface Sockets proposta na

década de 70 para o Unix Berkeley

23



Comunicação transiente orientada a mensagem Interface Berkeley: interface Sockets proposta na

década de 70 para o Unix Berkeley

24



Comunicação transiente orientada a mensagem Interface de troca de mensagem (MPI):

necessidade de interconexão em redes de alta velocidade (como as usadas por clusters) e uma interface que manipule características avançadas como diferentes formas de buffer e sincronização

Projetada para aplicações paralelas e independente de hardware e plataforma

25



Comunicação transiente orientada a mensagem

26



Comunicação persistente orientada a mensagem Objetivo: comparado a interface de Sockets e

MPI, o MOM normalmente visa o suporte de transferências de mensagens que têm a permissão de durar minutos em vez de segundos ou milissegundos

Conhecido como Middleware Oritentado a Mensagem (MOM)

27



Comunicação persistente orientada a mensagem Modelo de enfileiramento de mensagens

• Comunicação através da inserção de mensagens em filas específicas

• Um aspecto importante de sistemas de enfileiramento é que, em geral, um remetente só tem a garantia de que, a certa altura, sua mensagem será inserida na fila do receptor.

• Nenhuma garantia é dada sobre quando, nem ao menos se a mensagem será realmente lida, o que é totalmente determinado pelo comportamento do receptor

28




29




30



Comunicação persistente orientada a mensagem Brokers de Mensagens

• Uma importante área da aplicação de sistemas de enfileiramento é a integração de novas aplicações em um único e coerente sistema distribuído

• Desta forma as mensagens necessitam ter o mesmo formato para entendimento das aplicações

• Problema: para cada aplicação adicionada ao sistema que requer um formato diferente de mensagem, cada receptor potencial terá de ser ajustado de modo a produzir aquele formato

31




• Solução possível: formato comum, como é feito nos protocolos tradicionais de redes. Mas os processos que usam este formato devem ser muito em comum

• A abordagem geral é aprender a viver com diferentes formatos e tentar providenciar os meios para simplificar ao máximo as conversões

32




• Solução: uso de nós especiais, conhecidos como brokers de mensagens, para manipular as conversões de mensagens.

33




34



Comunicação persistente orientada a mensagem Exemplo de

sistema de

enfileiramento de

mensagens

35


Comunicação orientada a fluxo

Visto até agora: troca de informações completas e independentes. Ex.: RPC e troca de mensagens

Comunicação característica que não importa em que ponto particular do tempo a comunicação ocorra

Independente da comunicação ser muito lenta ou muito rápida

36



Em comunicação orientada a fluxo a temporização desempenha um papel crucial

Questão: quais são as facilidades que um sistema distribuído deve oferecer para trocar informações dependentes de tempo como fluxos de áudio e vídeo

37



Aplicação

file transfere-mail

Web documentsreal-time áudio/vídeo

stored áudio/videojogos interativos

Perdas

sem perdassem perdastolerantetolerante

tolerantetolerante

Banda

elásticaelásticaelásticaaúdio: 5 Kb-1 Mbvídeo:10 Kb-5 Mbigual à anterior kbps

Sensível ao atraso

nãonãonãosim, décimo de segundo

sim, alguns segundossim, décimo de segundo

Requisitos de transporte de aplicações comuns

38



Para capturar troca de informações dependentes do tempo, em geral os sistemas distribuídos fornecem suporte para fluxos de dados

Fluxo de dados: sequencia de de unidades de dados

Para capturar aspectos de temporização, costuma-se fazer uma distinção entre diferentes modos de trasmissão

39



Transmissão assíncrona: os itens de dados são transmitidos um após o outro mas não há restrição alguma de temporização. Ex.: fluxos discretos (textos, imagens estáticas)

Transmissão síncrona: há uma traso fim-a-fim máximo definido para cada unidade em um fluxo de dados. Não importa se uma unidade de dados for transferida com muito mais rapidez do que o atraso máximo tolerado

Transmissão isócrona: é necessário que as unidades de dados sejam transferidas no tempo certo. Deve haver atraso máximo e mínimo (variações de atraso delimitado). Interessante para sistemas distribuídos de multimídia

40



Fluxos (transmissão isócrona) podem ser simples ou complexos

Fluxo simples: consiste em uma única sequência de dados

Fluxo complexo: consiste em vários fluxos simples relacionados. Ex.: transmissão de filme, composto por um fluxo simples de vídeo, dois fluxos simples para transmitir o som estéreo e um fluxo contendo uma legenda. Tudo de forma síncronizada

41



42



Essa arquitetura geral revela algumas questões importantes:

Compressão dos dados de modo a reduzir o armazenamento requerido e em especial a capacidade da rede

Controle da qualidade da transmissão e questões de sincronização

43



Fluxos e qualidade de serviço Requisitos de temporização geralmente são expressos

como requisitos de Qualidade de Serviço (Quality of Service – QoS)

Assegura que as relações temporais em um fluxo possam ser preservadas

Refere-se à pontualidade, ao volume e à confiabilidade

44



Fluxos e qualidade de serviço Propriedades importantes

• A taxa de bits requerida à qual os dados devem ser transportados

• O máximo atraso até o estabelecimento de uma sessão, isto é, quando uma aplicação pode começar a enviar dados

• O máximo atraso fim-a-fim, isto é, quanto tempo levará até que uma unidade de dados chegue a um receptor

• A máxima variância de atraso, ou vibração• O máximo atraso de viagem de ida e volta

45



Fluxos e qualidade de serviço Dado que o sistema subjacente oferece apenas um serviço de

entrega de melhor esforço, um sistema distribuído pode tentar ocultar o máximo possível a falta de qualidade de serviço

Serviços diferenciados: diferenciar classe de dados (marcação de pacotes)

• Repasse acelerado: prioridade no repasse• Repasse garantido: dividido em quatro subclasses aliadas a

três modos de descartar pacotes se a rede ficar congestionada. Diferencia pacotes sensíveis ao tempo de pacotes não críticos

46



Fluxos e qualidade de serviço Outra solução é fazer uso de buffer

47



Sincronização de fluxos Manter relações temporais entre fluxos Duas formas de sincronização

• Sincronização entre fluxo discreto e contínuos. Ex.: Exibição de slides na Web

• Sincronização entre fluxos contínuos. Ex.: reprodução de vídeo e áudio, sincronização de lábios (lipsync)

48



Ex. sistema orientado ao fluxo (TV Digital)

Transporte dos dados

49



Ex. sistema orientado ao fluxo (TV Digital)

Visão geral do sistema de TV Digital

50


Comunicação multicast

Estabelecer caminhos de comunicação para a disseminação de informações

Várias soluções, por muitos anos, no nível de transporte e de redes

Envolve imenso esforço de gerenciamento, em muitos casos, exigia intervenção humanal

Com o advento do peer-to-peer e do gerenciamento estruturado de sobreposição, ficou mais fácil estabelecer caminhos de comunicação

51



Multicasting de nível de aplicação Objetivo: organização dos nós através de uma rede de

sobreposição para disseminar informações entre os nós desta rede

Problema: os dados podem cruzar vários enlaces físicos e o roteamento das mensagens dentro da rede de sobreposição pode não ser o ótimo em comparação com o roteamento da rede física

Duas soluções:• Organização em árvore → possui um único caminho• Organização em malha → cada nó terá vários vizinhos

52



Multicasting de nível de aplicação Ex. Árvore Multicast Chord

• Nó inicia sessão multicast gerando um identificador (mid) aleatório

• Consulta o nó responsável pelo identificador [succ(mid)]• Promoção do nó responsável pelo mid como raiz da

árvore• Para se juntar a árvore um nó P executa operação

lookup(mid)• Esta msg será roteada até ao nó raiz

53




• Caso a msg passe pelo nó Q e este não pertence a árvore, o nó se tornará um repassador para o grupo, enquanto o nó Q envia a msg de pesquisa até a raiz

• P se tornará filho de Q• Caso o nó Q já pertence a árvore este será um

repassador e não terá a necessidade de enviar a pesquisa de associação para o nó raiz

• O nó P, que requisitou a associação a árvore multicast, por definição, também é repassador

54




• A partir deste momento a comunicação é feita através do envio de uma msg multicast em direção à raiz da árvore simplesmente executando o comando lookup(mid), após a qual a msg pode ser enviada ao longo da árvore

55



Multicasting de nível de aplicação Construção da sobreposição

• Embora construir uma árvore seja um processo relativamente fácil, construir uma árvore eficiente pode ser uma histório bem diferente

56



Multicasting de nível de aplicação Construção da sobreposição

• Qualidade da árvore multicast medida em três parâmetros:– Estresse de enlace: definido por enlace e conta

quantas vezes um pacote cruza o mesmo enlace– Alongamento: razão entre o atraso entre dois nós na

sobreposição e o atraso que esses dois nós sofreriam na rede subjacente

– Custo da árvore: está relacionado com a minimização dos custos agregados de enlaces. Ex.: encontrar a spanning tree mínima

57



Disseminação de dados baseada em gossiping Disseminar informações através de um

comportamento epidêmico Espalhar informações em larga escala semelhante ao

espalhamento de enfermidades através de pessoas Objetivo: propagar informações rapidamente entre

entre um grande conjunto de nós usando somente informações locais, sem a necessidade de um componente central que coordena a disseminação de informações

58



Disseminação de dados baseada em gossiping Um nó que é parte do sistema distribuído é

denominado:• Infectado: se contiver dados que está disposto

a espalhar para os outros nós• Suscetível: nó que ainda não tenha visto esses

dados• Removido: nó atualizado que não está disposto

ou capacitado para propagar os dados

59



Disseminação de dados baseada em gossiping Um modelo popular de propagação é o da

antientropia onde um nó P escolhe aleatoriamente um outro nó Q e na sequencia troca atualizações com este último

• Três abordagens para a troca de atualizações:– P só troca suas próprias atualizações com Q– P só recebe novas atualizações de Q– P e Q enviam atualizações um ao outro

60



Disseminação de dados baseada em gossiping Funcionamento do gossiping

• Se o nó P acabou de ser atualizado com o item de dado x, ele contata um outro nó arbitrário Q e tenta enviar a atualização a Q

• Contudo, é possível uqe Q já tenha sido atualizado por um outro nó

• Nesse caso, P pode perder o interesse em levar adiante a propagação da atualização, tornando-se nó removido

• Gossiping mostrou ser um modo excelente de espalhar notícias rapidamente, porém não garante que todos os nós realmente serão atualizados

Combinar antientropia com gossiping resolve o problema

61



Disseminação de dados baseada em gossiping Remoção dos dados

• Algoritmos epidêmicos são bons para propagar atualizações

• Contudo propagar remoção de um item de dado é difícil

• Remover um item significa destruição de todas as informações deste item. Com isso o nó que destruiu este item pode receber cópia antiga deste e interpretar como uma atualização

• Solução: propagação de certificados de óbito

62


Comunicação multicast (camada de Rede)

Entrega de pacotes a apenas um subgrupo na rede

Alguns questionamentos: Como identificar os destinatários de um pacote (subgrupo)? Como um grupo multicast começa e termina? Como os nós da rede interagem para entregar um

datagrama de grupo a todos os membros desse grupo? Como é escolhido o endereço?

Para a Internet as respostas para estas perguntas envolve o Protocolo de Gerenciamento de Grupo da Internet (IGMP)

63



Entrega de pacotes aos membros do grupo multicast

64



Internet Group Management Protocol Oferece meios para um nó informar ao roteador

conectado a ele que uma aplicação que está funcionando nele quer se juntar a um grupo específico

Como a intereção do IGMP é limitada a um nó e ao roteador diretamente conectado, é necessário um protocolo responsável pelo roteamento dos datagramas aos destinos finais

Assim, o serviço de grupo na camada de rede da Internet consiste em dois componentes complementares: IGMP e protocolos de roteamento de grupo

65



Internet Group Management Protocol

66



Funcionamento IGMP O roteador envia msg membership_query a uma rede local para

todos os nós desta rede para determinar o conjunto de todos os grupos aos quais se ligaram os nós naquela interface.

Os nós respondem com uma msg membership_report. Esta msg pode ser gerada pelo nó sem esperar por uma msg membership_query caso a aplicação deste nó queira se juntar a um determinado grupo multicast

Uma msg leave_group (opcional) pode ser enviada por um nó ao roteador informando seu desligamento no grupo. Mas de tempo em tempo caso um nó não responda a uma msg membership_query enviada pelo roteador, este deduz que o nó não pertence mais ao grupo

67



Algoritmos de roteamento para grupos Duas abordagens adotadas para determinar a

árvore de roteamento para um grupo• Árvore compartilhada → baseado na construção

de uma árvore que inclui todos os roteadores de borda cujos nós a ele conectados pertencem ao grupo (spanning tree)

• Árvore baseada na origem → construção de uma árvore de roteamento para um grupo para cada origem do grupo

68



Algoritmos de roteamento para grupos

69



Construção de uma spanning tree com centro

estratégia de trabalho - departamento de ciência da ... · escondem absolutamente nada da...

Documents