Sistemas Operacionais II

Transcrição

1 Introdução Instituto de Informátic ca - UFRGS Sistemas Operacionais II Remote Procedure Call - RPC Aula 13 Necessidade de desenvolver aplicações distribuídas de forma simples Solução: estender modelos de programação convencionais Três modelos: Procedural: chamada remota de procedimentos (RPC) Orientado a objetos: invocação remota de métodos (RMI) Baseado em eventos: atendimento de eventos remotos Provido através de um middleware de comunicação Síncrono Assíncrono Software que provê um modelo de programação oferecendo abstração de processos, comunicação e serviços através de primitivas próprias Sistemas Operacionais II 2 Aspectos importantes (ideais) de um middleware Remote Procedure Call (RPC) Transparência de localização Mesmo comportamento (sintaxe e semântica) independente dos procedimentos serem locais ou remotos Fornecer protocolo de comunicação independente do de transporte Independência de plataforma (hardware e sistema operacional) Uso de representação externa de dados Primitivas para criação de fluxos de execução, sincronização, etc, independentes do sistema operacional Uso de linguagens de programação Permitir ou não o emprego de várias linguagens de programação no desenvolvimento da aplicação distribuída Generalização do conceito de subrotinas Permite um programa chamar um procedimento que não se encontra no espaço de endereçamento do processo Espaço pç de usuário Espaço pç de usuário Espaço pç de usuário Aplicação Biblioteca System calls Espaço de sistema 1 2 Aplicação Stub cliente runtime 10 9 Espaço de sistema Aplicação Stub servidor runtime 4 5 Espaço de sistema Sistemas Operacionais II 3 Sistemas Operacionais II 4

2 Implementação do mecanismo de RPC Stubs Oferece transparência sintática através de quatro elementos stub cliente, runtime, stub servidor, dispatcher Middleware (runtime) Responsável pelo envio de mensagens entre cliente e servidor Implementa um protocolo da família request-replyreply independente da camada de transporte Provê mecanismos para retentativas, time-out, codificação de dados, etc Geração de stubs Manualmente: programador constrói os stubs e parâmetros Automaticamente: baseado em uma IDL! Compilador IDL gera código a ser integrado ao do programador Implementações ocas dos procedimentos Stub cliente Executa o marshalling dos argumentos Envio de uma mensagem (requisição) ao processo servidor Bloqueia até receber mensagem (resposta) Efetua unmarshalling e repassa a aplicação Stub servidor Espera por requisições Executa o unmarshalling dos argumentos Chama o procedimento associado (chamada local) Dispatcher Executa o marshalling do resultado Envia mensagem para o processo cliente Sistemas Operacionais II 5 Sistemas Operacionais II 6 Interfaces Semântica de passagem de parâmetros Aplicação distribuída = conjunto de módulos que comunicam entre si Descrição de procedimentos e de variáveis que podem ser acessadas por outros módulos Nome Parâmetros de entrada e de saída (inclui tipos) Passagem de parâmetros por valor e/ou por referência Passagem de parâmetros é problemática para modelo distribuído e.g.: não faz sentido passar ponteiros Passagem por valor Parâmetros são copiados na mensagem e enviados ao servidor Não representa maiores problemas Passagem por referência Sem sentido, em princípio, pois não há espaço de endereçamento comum Soluções possíveis:! Empregar uma passagem de parâmetros do tipo call-by-copy/restore! Solução: descrever parâmetros na forma entrada/saída Entrada: enviados ao módulo remoto (mensagem de requisição) Saída: recebido pelo módulo solicitante (mensagem de resposta)! Resolver o ponteiro a cada referência no servidor (mensagens adicionais)! Usar mecanismos de DSM (Distributed Shared Memory) Sistemas Operacionais II 7 Sistemas Operacionais II 8

3 Interface Description Language (IDL) Transparência: Localização de serviços Interface de serviços (modelo RPC) Especificação de procedimentos + argumentos (entrada/saída) Interface remota (modelo RMI) Especificação de métodos + argumentos (entrada/saída) Nt Notação para definir dfiiit interfaces Integrado diretamente em uma linguagem (e.g.: java RMI) Mapeado (compilado) para uma linguagem específica (e.g.: C, C++, etc) Descrição da interface Compilador IDL (gerador) Interface descrita linguagem alvo Stub cliente necessita descobrir o servidor antes de realizar RPC Para quem ele deve enviar a mensagem?? Procedimento de binding (amarração) Tabela de mapeamento serviço versus servidor Publicação e consulta de serviços Sistemas Operacionais II 9 Sistemas Operacionais II 10 Remote Procedure Call versus Local Procedure Call Questões sobre transparência Quatro propriedades de aplicações distribuídas que dificultam a idéia da transparência Falhas parciais Concorrência Latência Acesso a memória Leslie Lamport (funny definition): A distributed system is one in which the failure of a computer you didn t ever know existed can render your own computer unusable Em RPC fácil oferecer transparência sintática, porém não semântica Variáveis globais (como fazer?) Problema com passagem de parâmetros por referência Vulnerabilidade a falhas! Mensagens (request/reply) podem ser perdidas! Servidor pode pendurar (antes ou depois de ter executado a requisição??)! Cliente pode pendurar (antes ou depois de ter aceito o resultado??) A concorrência é real (processo local e processo remoto) Latência na execução! Tempo de execução é sensível a atrasos na rede Conclusão: transparência semântica é difícil de ser obtida e nem sempre é desejável Necessidade da reagir adequadamente a condições de falhas Sistemas Operacionais II 11 Sistemas Operacionais II 12

4 Execução de serviços remotos na presença de falhas Falhas no servidor Pontos de falhas por colapso: cliente, servidor, rede O problema é saber se a falha ocorreu antes ou depois de ter executado a requisição Protocolo de transporte pode auxiliar Clientes e servidores baseados em UDP não conseguem determinar a origem da falha (cliente, servidor ou rede) Clientes e servidores baseados em TCP tem a possibilidade de identificar problemas com o reset da conexão (segmento com flag de FIN)! Nem sempre é possível usar esse recurso Solução é tratar falhas com outras técnicas Definir uma semântica de invocação No máximo uma vez (at most once) Pelo menos uma vez (at least once) Exatamente uma vez (exactly once) Implementar operações idempotentes Sistemas Operacionais II 13 Sistemas Operacionais II 14 Operações idempotentes Falha no cliente Aquelas que podem ser realizadas n vezes fornecendo o mesmo resultado como tivessem sido executadas uma só vez e.g.: ler um bloco de dados de um arquivo, inserir um elemento em uma posição fixa de um vetor etc Não idempotente: o resultado final é modificado pela reexecução e.g.: creditar ou debitar um valor em uma conta bancária, inserir ou remover um elemento em um vetor etc Operações idempotentes simplificam a execução de serviços remotos em caso de falhas Possível tornar operações não idempotentes em idempotentes! Números de sequência e históricos! Flag indicativo de reenvio (original é executada sem problemas, reenvios exigem cuidados adicionais) Cliente pendura após ter enviado a requisição Reiniciar o cliente (processo e/ou máquina), porém conseqüência é se ter uma computação orfã Problemas com computações orfãs Desperdício de cpu no servidor, locks realizados no cliente e não liberados, confusão com a resposta que chega (quem fez?), problemas com números de seqüência etc Soluções possíveis: Extermínio Reencarnação Expiração Sistemas Operacionais II 15 Sistemas Operacionais II 16

5 Estratégias Falha na rede Extermínio: baseado em um log Cliente loga tudo que executa e em caso de reboot anula todos resquícios de computações orfãs Reincarnação: baseado em épocas Cada reboot gera um número que é usado para identificar request e reply Anula tudo que pertence a uma época anterior a atual Expiração: determinar um tempo máximo para uma serviço remoto ser feito Visões distintas O cliente enxerga como uma falha do servidor O servidor enxerga como uma falha do cliente Ocorrerão timeout e retransmissões Tratamento e ações dependem da semântica adotada Sistemas Operacionais II 17 Sistemas Operacionais II 18 Estudo de caso: Sun RPC Desenvolvimento em Sun RPC Projetado para o NFS (Network File System) Ações NFS são idempotentes: semântica adotada é at-least-once! Se usado em outro contexto, cabe ao usuário fazer tratamento adequado Define uma linguagem (XDR) e um compilador IDL (rpcgen) Características ti gerais: Permite apenas um parâmetro in/out! Uso de structs para permitir mais campos Não fornece servidor de nome global! Usa portmapper : servidor de nome local (porta x procedimento)! Cliente deve obter a porta onde o serviço executa, mas tem que conhecer a máquina que executa o serviço (endereço IP ou nome DNS simbólico) Como usar um procedimento remoto? Escrever uma definição de interface usando XDR! Contém a especificação da do procedimento remoto e parâmetro Compilar com rpcgen gerando:! Stub client! Stub servidor e procedimento remoto! Arquivo.h! Duas duas funções de manipulação de parâmetros a serem usadas pelo cliente e pelo servidor (fazem o marshaling e o unmarshaling) Programa cliente é escrito, compilado e ligado junto com o stub cliente (usa o arquivo.h) Programa servidor é escrito, compilado e ligado junto com o stub servidor (usa o arquivo.h) Sistemas Operacionais II 19 Sistemas Operacionais II 20

6 Exemplo: rpcgen (Sun RPC IDL) Passos envolvidos na execução de square gcc o server server.c square_svc.c square_xdr.c -lrpcsvc server.c square_svc.c gcc server client.c Processo cliente Rotinas cliente 1 10 Processo servidor Rotinas servidor 6 5 server.c square_xdr.c square.x rpcgen lib lrpcsvc (no linux) rpcgen square.x square.h square_clt.c client.c gcc client gcc o client client.c square_clt.c square_xdr.c -lrpcsvc Exemplo completo com os fontes no moodle (servidor de elevar ao quadrado) square_clnt.c square_xdr.c 2 Stub cliente Runtime RPC Stub servidor Runtime RPC 4 square_svc.c square_xdr.c usuário kernel Sistemas Operacionais II 21 Sistemas Operacionais II 22 Leituras adicionais Couloris, G; Dollimore, J; Kindberg, T. Distributed Systems: Concepts and Design (4 th edition), Addison Wesley, 2005 Capítulo 5 (seção 5.3) Sistemas Operacionais II 23