A apresentação está carregando. Por favor, espere

A apresentação está carregando. Por favor, espere

Sistemas Distribuídos Professor Luiz José Hoffmann filho

Apresentações semelhantes


Apresentação em tema: "Sistemas Distribuídos Professor Luiz José Hoffmann filho"— Transcrição da apresentação:

1 Sistemas Distribuídos Professor Luiz José Hoffmann filho ljhfilho@gmail.com

2 Comunicação-Protocolos, tipos, RPC Capitulo 4

3 Agenda Protocolos em camadas Pilhas de protocolos e Sistemas Distribuídos Tipos de comunicação (camada de Middleware) Persistência e sincronização Camanda de Procedimento Remoto (RPC) Operação Básica Passagem de Parâmetros Comunicação orientada a mensagem Comunicação transiente: MPI Comunicação persistente: Sistema de enfileiramento de Mensagens Comunicação Orientada a fluxo Tipos de fluxo Qualidade de Serviço

4 Comunicação entre Processos “Coração” de qualquer Sistema Distribuído Como processos em diferentess máquinas trocam informações? Não é uma tarefa trivial!! Desejável obter modelos onde a complexidade da comunicação seja transparente para o desenvolvedor.

5 Participantes são divididos em: – Servidores: implementam um serviço específico – Clientes: solicitam ao servidor um determinado serviço e espera pela resposta Comportamento requisição-resposta Modelo Cliente-Servidor

6 Protocolos em Camadas

7

8 Responsável pelo envio de bits Trata da padronização das interfaces elétrica, mecânica e de sinalização Protocolos são dependentes do meio de transmissão do link Camada Física

9 Responsável pelo envio de frames entre os links Característica importante: um datagrama pode ser manipulado por diferentes tipos de protocolos da camada de enlace: Ethernet (CSMA/CD), PPP Cada protocolo diferente pode ou não implementar um conjunto de serviços. Ex.: entrega confiável da informação Camada de Enlace

10 Redes de longa distância são constituídas de muitos nós com diferente caminhos entre eles. Como definir um caminho entre um par origem-destino? Roteamento é a principal tarefa da camada de rede Internet Protocol: protocolo sem conexão, onde pacotes são roteados de forma independente – best-effort service Camada de Redes

11 Responsável pela comunicação lógica entre diferentes processos sendo executados em diferentes hosts (fim-a-fim) Protocolos da camada de transporte não estão implementados nos roteadores Pode fornecer os seguintes serviços: – multiplexing/demultiplexing – transmissão confiável – garantias de banda, retardo Camada de Transporte

12 Transmission Control Protocol (TCP) – Orientado a Conexão – Confiável, porém “lento” Universal Datagram Protocol (UDP) – Sem conexão – “Rápido”, porém não confiável Escolha está ligada as caracteristicas da aplicação! Protocolos de Transporte na Internet

13 Distinção entre aplicação para redes e protocolos da camada de aplicação – Protocolo: pequena (talvez grande) peça de uma aplicação Ex.1: Aplicação WEB → HTTP Ex.2: Aplicação Email → SMTP Protocolos definem: tipos de mensagens trocadas, sintaxe Camada de Aplicação

14 Camada de software que é situada logicamente entre uma camada de nível mais alto, composta de usuários e aplicações e uma camada subjacente, que consiste de facilidades básicas de comunicação Inúmeros protocos para suportar serviços de middleware: – Autenticação: não estão vinculados a uma aplicação – Comprometimento – Comunicação: Serviços de comunicação de alto nível Camada de Middleware

15

16 Como os processos executando em diferentes máquinas trocam informação? – Em uma visão pilha de protocolos TCP/IP → Enviando mensagens através da utilização de sockets Socket: ponto final de uma comunicação full- duplex entre dois processos – Processo → casa / Socket → Porta – Socket: Porta entre o processo da aplicação e o protocolo de transporte (Sockets)

17 Informações são string de bytes, sem significado aparente Não existe a transparência de distribuição: toda a comunicacão está está explícita, através de procedimentos send e receive – Funções mais sofisticadas devem ser feitas na camada de aplicação Por que não oferecer comunicação de alto nível, indepedente da aplicação? (Sockets)

18 Solução!!!! Middleware de comunicação Tipos Chamadas de Procedimento Remoto Comunicação orientada a Mensagens Comunicação Orientada a Fluxo

19 Persistência – Persistente: Mensagem é armazenada pelo middleware de comunicação durante o tempo que for necessário para entregá-la ao receptor. – Transiente: Mensagem é armazenada somente durante o tempo em que a aplicação remetente e a aplicação receptora estiverem executando Tipos de Comunicação (Middleware)

20 Sincronização – Assíncrona: Remetente continua sua execução imediatamente após ter apresentado sua mensagem para transmissão – Síncrona: Remetente é bloqueado até saber que sua requisição foi aceita –Middleware avise que se encarregará da transmissão –Requisiçao ser entregue ao receptor –Ate o instante que o receptor retornar uma resposta Tipos de Comunicação (Middleware)

21 Granularidade – Discreta: Partes se comunicam por mensagens e cada mensagem forma uma unidade de informação completa – Fluxo: Várias mensagens,sendo que as mensagens estão relacionadas uma com as outras pela ordem ou pela relação temporal Tipos de Comunicação (Middleware)

22 Birrell and Nelson (1984) “Permite a processos chamar procedimentos localizados em outras máquinas” Desenvolvedor não precisa se preocupar mais com detalhes de implementação de rede (sockets nunca mais!) Conceitualmente simples, mas... Chamada de Procedimento Remoto

23 Arquiteturas de duas máquinas podem ser diferentes Espaço de endereçamento diversos Passagem de parâmetros RPC - Complicações

24 A idéia fundamental é fazer com que uma chamada de procedimento remoto pareça com uma chamada local Transparência RPC – Como funciona??

25 Transparência conseguida com o uso de stubs (apêndices) Stub do cliente responsável por empacotar os parâmetros em uma msg e enviar a msg para a máquina do servidor. Quando resposta chega, resultado é copiado para cliente, e controle volta a ele Stub do servidor responsável por desempacotar parâmetros, chamar o procedimento do servidor e retornar resposta para máquina do cliente RPC – Como Funciona??

26 Cliente Empacota Parâmetros Desempacota Resultado Chamada Retorno Servidor Desempacota Chamada Parâmetros Empacota Retorno Resultado Máquina Cliente Máquina Servidora Transporte de mensagens na rede Stub do Cliente SO Stub do Servidor SO RPC – Como Funciona?

27 RPC – Como Funciona??

28 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. Procedimento do cliente chama stub cliente de modo usual Stub do cliente constrói uma msg e chama o SO SO envia msg para SO remoto SO remoto repassa msg para stub do servidor Stub do servidor desempacota parâmetros e chama procedimento servidor Procedimento servidor executa e retorna o resultado Stub do servidor empacota resultado em uma msg e chama SO SO remoto envia msg para SO da máquina cliente SO do cliente passa msg para stub cliente Stub cliente desempacota resultado, repassando-o para o cliente Passos seguidos por um RPC

29 Função do stub do cliente é pegar seus parâmetros, empacotá-los em uma mensagem e enviá-los ao stub do servidor (montagem de parâmetros - parameter marshaling). Operação parece simples, mas: Arquiteturas diferentes? Passagem de ponteiros (diferente espaço de endereçamento)? RPC – Passagem de Parâmetros

30 RPC – Passagem de Parâmetros por valor

31 A chamada do procedimento remoto add somente funcionará se as máquinas do cliente e do servidor forem idênticas Problemas: – Representação diferentes para caracteres – Ordenação de bytes Solução: Cliente diz seu tipo. Conversão feita pelo servidor se tipos forem diferentes. RPC – Passagem de Parâmetros por valor

32 Problema: um ponteiro é significativo somente dentro do espaço de endereço do processo no qual está sendo usado read(fd,buf,nbytes) (executado no servidor de arquivos) fd → inteiro que indica um arquivo buf → endereço do vetor de caracteres nbytes → total de bytes a serem lidos RPC – Passagem de Parâmetros por referência

33 Mecanismo de passagem de parâmetro → copiar/restaurar – Variável é copiada na pilha do cliente (passagem de parâmetro por valor) – Variável é manipulada no servidor – Valor de retorno sobreescreve o valor original na pilha do cliente RPC – Passagem de parâmetro por referência

34 No caso do read, stub do cliente “sabe” que o segundo parâmetro aponta para um conjunto de caracteres Suponha que o cliente saiba o tamanho do vetor Solução: – Copiar o vetor para a mensagem e enviar ao servidor – Stub do servidor, chama o servidor com um ponteiro para este vetor – Modificação feita pelo servidor é armazenada diretamente no vetor que está no stub – Ao enviar o vetor de volta ao stub do cliente, o vetor é copiado de volta ao cliente RPC – Passagem de Parâmetros por referência

35 Interface consiste em um conjunto de procedimentos que podem ser chamados por um cliente e que são implementados por um servidor Utilização de interface simplifica consideravelmente aplicações cliente-servidor baseadas em RPCs Gerar completamente stubs de cliente e servidor - todos os sistemas de middleware baseados em RPC oferecem uma IDL para suportar desenvolvimento de aplicação RPC – Linguagem de programação de interface - IDL

36 Permite a um cliente o acesso a um serviço remoto por meio de uma simples chamada a um procedimento local Possibilita que programas clientes sejam escritos de modo simples Pode localizar automaticamente o servidor correto Estabelece a comunicação entre software cliente e software servidor RPC – Resumindo …

37 Comomecanismos de comunicação, RPC e RMI podem ser inadequados O que acontece caso não seja possível considerar que o receptor esteja sempre 'acordado'? Comportamento padrão <sincronismo,bloqueia> é muito restritivo Como contornar estas limitações: Mensagens Comunicação orientada a mensagem

38 Com multicomputadores de alto desempenho, desenvolvedores começaram a procurar primitivas orientadas a mensagem Objetivo: Escrever com facilidade aplicações de alta eficiência Necessidade de independência de hardware e de plataforma Interface de troca de mensagens (MPI)

39 Considerado como um padrão de troca de mensagens para escrever programas paralelos a serem executados em clusters Comunicação transiente → mensagem é armazenada no sistema enquanto remetente e receptor estiverem ativos Interface de troca de mensagens (MPI)

40 A comunicação ocorre dentro de um grupo conhecido de processos Cada grupo recebe um identificador Cada processo dentro de um grupo recebe um indentificador Par (groupID,processID) identifica fonte ou destinatário de uma mensagem Vários grupos de processos poderão estar envolvidos em um serviço de computação, podendo estar em execução ao mesmo tempo MPI – Como Funciona??

41 Mais de 100 funções diferentes para troca de mensagens: – MPI_recv → recebimento de mensagem; bloqueia o chamador até chegar uma mensagem – MPI_irecv → receptor pode verificar se a mensagem realmente chegou ou não – MPI_ALLtoall → distribui igualmente os dados entre todos os nós participantes da computação IBM, Intel, TMC, Meiko, Cray, Convex, Ncube MPI

42 Conhecidos como sistemas de enfileiramento de mensagens Suporte para comunicação assíncrona persistente Capacidade de armazenamento de médio prazo para as mensagens trocadas Idéia básica: Aplicações se comunicam retirando e colocando mensagens em filas específicas Mensagem será eventualmente entregue ao receptor Middleware orientado a mensagem (MOM)

43 Consulta que abranja vários bancos de dados pode ser repartida em subconsultas que são repassadas para bancos de dados individuais. Sistemas de enfileiramento de mensagens ajudam fornecendo meios básicos para empacotar cada subconsulta em uma mensagem e roteá-la até o banco de dados adequado. MOM - Exemplo

44 E-mail, fluxo de trabalho, groupware,processamento em lotes, integração de banco de dados e aplicações MOM – Outras Aplicações

45 1 – Aplicações se comunicam inserindo mensagens em filas específicas 2 – Mensagens são repassadas por uma série de servidores de comunicação 3 – Mensagens são entregues ao destinatário, mesmo que ele não esteja em funcionamento quando a mensagem foi enviada Remetente e Receptor podem executar em completa independência MOM – Como funciona?

46 MOM – Estados do Remetente e Receptor

47 Mensagens podem conter qualquer tipo de dado Mensagens devem ser adequadamente endereçadas O endereçamento é feito com o fornecimento de um nome exclusivo da fila destinatária no âmbito do sistema MOM – Características das Mensagens

48 Fila de Fonte Fila de Destino Gerenciadores de Fila Repassadores MOM – Arquitetura Geral

49 Fila de Fonte: Fila na qual o remetente envia a mensagem. Estas filas são filas locais do remetente Fila de Destino: Uma mensagem colocada em uma fila contém a especificação de uma fila de destino para a qual ela deve ser transferida MOM – Arquitetura Geral

50 MOM – Como encontrar uma fila dentro do sistema?

51 Gerenciadores de Fila: Um gerenciador de fila interage diretamente com a aplicação que está enviando ou recebendo uma mensagem Repassadores: Repassam mensagens que chegam para outros gerenciadores de fila. Sistema de enfileiramento de mensagens pode crescer até uma rede de sobreposição (overlay) completa de nível de aplicação MOM – Arquitetura Geral

52

53 Repassadores podem ajudar a construir sistemas escaláveis de gerenciamento de fila Atualizações de remoção e adição de filas devem ser feitas somente nos repassadores Gerenciadores de fila somente devem saber onde está o repassador mais próximo MOM - Repassadores

54 Sistemas de E-mail: – Requisitos de filtragem automática de mensagens – Não precisam garantir entrega de mensagens, prioridades de mensagens, facilidades de registro, balanceamento de carga, tolerância a falha Sistemas de Enfileiramento de Mensagens versus E-mail

55 Sistemas de Enfileiramento de Mensagens – Fornece recursos mais amplos para tratamento de diversas aplicações diferentes – Possibilitam comunicação persistente entre processos – Manipular acesso a banco de dados – Realizar cálculos – Prioridades de mensagens Sistemas de Enfileiramento de Mensagens versus E-mail

56 Troca de unidades de informação mais ou menos completas e independentes Ex: Requisição para invocar um procedimento Quais são as facilidades que um sistema distribuído deve oferecer para trocar informaçõees dependentes de tempo (fluxos de áudio e vídeo)? TEMPO É CRUCIAL!!! Até o momento…

57 Fluxos Simples – Sequência simples de dados. – Ex: Voz Fluxos “Complexos” – Consiste em vários fluxos simples relacionados denominados subfluxos – Relação temporal entre os subfluxos – Ex: Transmissão de um filme: vídeo,som, legenda Comunicação Orientada a Fluxo – Tipos de Fluxos

58 Requisitos que descrevem o que é necessário para garantir que as relações temporais em um fluxo possam ser preservadas Está relacionada com: – Pontualidade – Volume – Confiabilidade Sistemas operacionais e redes não suportam QoS!!! → Serviço IP é best-effort Qualidade de Serviço (QoS)

59 Serviço Diferenciados Bufferização para reduzir variância de atraso no receptor Como Garantir QoS?(1)

60 Idéia Básica: Nós se organizam em uma rede de sobreposição que é usada para disseminar informações para seus membros Nós na rede de sobreposição podem cruzar vários enlaces físicos: roteamente pode não ser ótimo Construção do overlay – Árvore: único caminho entre cada par de nós – Malha: Cada nó terá vários vizinhos, em geral, existem vários caminhos entre cada par de nós Multicasting de Nível de Aplicação

61 No caso da estrutura em árvore, o problema é construir uma árvore eficiente! Multicasting de Nível de Aplicação (MNA)

62 Correção de Erro de Envio (Forward Error Correction - FEC) Como garantir QoS? (2)

63 Estresse de enlace: Quantas vezes uma mensagem atravessa o mesmo enlace? Exemplo: mensagem de A a D atravessa Ra,Rb duas vezes Penalidade de atraso relativo: Razão entre o atraso entre dois nós na sobreposição e o atraso que esses dois nós sofreriam na rede subjacente. Exemplo: mensagens de B a C possuem um atraso de 71 no overlay, mas de 47 no nível de rede, que gera uma penalidade de 1.51 Custo da árvore: parâmetro de medição global, relacionado com a minimização dos custos agregados de enlaces. Exemplo: atraso entre dois nós finais → spanning tree MNA – Qualidade da estrutura

64 Idéia Básica: propagar informações rapidamente entre um grande conjunto de nós usando somente informações locais. Não há nenhum componente central que coordena a disseminaçã o de informações. Atualizações para um item de dado específico são iniciadas em um único nó, evitando conflito de escrita. Disseminação de Dados – Algoritmos Epidêmicos

65 Três tipos de nós: – Infectado: se contiver dados que está disposto a espalhar para 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. Modelos de Disseminação de Dados

66 Idéia Básica: Um nó P escolhe aleatoriamente um outro nó Q : Push: P envia suas próprias atualizações a Q Pull: P recebe novas atualizações de Q Push-Pull: P e Q enviam atualizações um ao outro, (abordagem enviar-receber) Antientropia

67 Idéia Básica: Se um nó P acabou de ser atualizado com o item de dado x, ele contata um nó arbitrário Q e tenta enviar a atualização a Q. Contudo, é possível que 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, com probabilidade 1/k Problema: Nós poderão não receber atualizações! Gossiping


Carregar ppt "Sistemas Distribuídos Professor Luiz José Hoffmann filho"

Apresentações semelhantes


Anúncios Google