A Note on Distributed Computing
Jim Waldo, Geoff Wyant, Ann Wollrath, Sam Kendall
(Apresentado por Aliandro Lima)
Roteiro Introdução; Visão unificada de Objetos; Computação local Vs computação
distribuída; Latência; Acesso à memória; Falhas parciais; Concorrência.
O mito da qualidade de serviço; O caminho das pedras... (conclusões)
Introdução No mundo da computação sempre existiu
muito esforço para facilitar a vida do programador (tornar seu trabalho mais simples);
Orientação a Objetos é um esforço nesse sentido;
Esforço semelhante tem sido feito na intenção de simplificar o desenvolvimento de aplicações distribuídas (Objetos distribuídos).
Orientação a Objetos O conceito de Orientação a objetos
considera vários aspectos: Especificação de um conjunto de interfaces
para um objeto; Especificação de uma semântica para as
operações em um objeto; Encapsulamento, polimorfismo, herança...
Porém, não contempla localização: Localização costuma ser tratado como um
aspecto de implementação;
Localização Local Computing = mesmo espaço de
endereçamento;
Distributed Computing = espaços de endereçamento diferentes, possivelmente em máquinas diferentes;
Distributed ≠ concorrente;
Visão unificada de objetos
Objeto B
IDL
Frameworkou
middleware
Frameworkou
middleware
Objeto A
IDL
Invocação Local = Invocação RemotaInvocação Local = Invocação Remota
Justificativa para a unificação Localidade não causa impacto na
corretude de um programa; Se um programa calcula a soma de dois
números, ele o fará corretamente independente de localização, desde que implementado corretamente;
Esconder localidade do programador parece uma questão de implementação bastante razoável;
Isso nos dá facilidade de manutenção.
Princípios Existe um único paradigma de orientação
a objetos, independente da localização dos mesmos;
Aspectos relacionados a falhas e performance são contemplados na hora da implementação e devem ser deixados de lado na hora do projeto;
A interface de um objeto é independente do contexto em que este é usado.
Problema Porém, programar aplicações distribuídas
não é a mesma coisa de programar aplicações locais;
Unificar o paradigma de comunicação com o paradigma de linguagem não é suficiente para facilitar a programação distribuída, pois comunicação não é a parte difícil;
Dificuldades em computação distribuída Lidar com falhas parciais na ausência de
um gerente central de recursos;
Garantir performance e lidar com problemas de concorrência;
Lidar com diferentes formas de acesso à memória para objetos locais e distribuídos.
Local and Distributed Computing Latência;
Acesso à memória;
Falhas parciais;
Concorrência.
Latência Diferença óbvia; Diferença em torno de quatro ou cinco
ordens de magnitude; Ignorar tal diferença pode trazer sérios
problemas de performance; É preciso considerar latência na hora de
escolher que objetos de aplicação podem ser remotos e quais devem ser agrupados proximamente.
Latência Logo, considerar latência consiste em
inserir um passo extra no desenvolvimento de uma aplicação distribuída: identificar o padrão de comunicação entre os objetos que formam a aplicação.
Ferramentas são necessárias para ajudar nessa tarefa (identificar padrões na comunicação das entidades);
Latência Pode-se argumentar que no futuro, a
diferença de tempo entre chamadas locais e remotas será indistinguível;
No entanto, latência não é a única diferença entre chamadas locais e remotas. É apenas a mais óbvia;
Por ser a mais óbvia, muitos a consideram como a única;
Acesso à memória Ponteiros x Referências; Ponteiros em um espaço de
endereçamento local não são válidos em outro espaço (remoto) de endereçamento;
Neste caso, temos duas opções: O middleware controlar todos os acessos à
memória; ou Tornar explícito para o programador a
diferença entre acessos locais e remotos.
Acesso à memória Para se ter uma visão unificada, é
possível: Prover memória compartilhada distribuída; Eliminar o uso de ponteiros, usando objetos
sempre que um ponteiro era antes usado. Eliminar ponteiros muda o paradigma
local. Programadores precisarão ter um novo estilo de programação.
Como referenciar remotamente o que não é objeto?
Acesso à memória Se não é possível manter uma visão
unificada, o programador precisa saber disso;
Se a visão é unificada, mas muda o paradigma local, o programador também precisa saber disso;
Falhas parciais É logicamente possível que as diferenças
referentes à latência e acesso à memória sejam escondidas por uma visão unificada;
Entretanto, não parece ser logicamente possível fazer o mesmo para esconder as diferenças referentes a falhas e concorrência.
Falhas em sistemas locais Podem ser falhas totais:
afetam todas as entidades que executam em conjunto em uma aplicação.
ou detectáveis através de algum gerente de recursos central: Sistema operacional ou o próprio “main” do
programa. É fácil determinar qual erro aconteceu.
Falhas em sistemas distribuídos Falhas parciais:
Um componente falha (máquina, link, processo...) e outro continua executando (falhas independentes);
Não existe uma entidade comum que possa determinar quando um componente falhou e avisar a todos os outros;
É mais difícil determinar o erro exato; Falha de um link é indistinguível de uma
falha de processo.
Falhas em sistemas distribuídos É preciso assegurar que o estado do
sistema inteiro é consistente após uma falha; Não temos isso em computação local;
As interfaces do sistema devem ser projetadas de forma que seja possível reagir a uma falha de maneira consistente; interfaces para identificar a causa de uma falha; Interfaces para reconstruir um estado
consistente diante de uma falha.
Buscando um modelo unificado Alternativa 1:
Tratar todos os objetos como sendo locais; Projetar as interfaces como se a comunicação
fosse sempre local; Sistemas distribuídos neste modelo se
comportam de maneira não determinística diante de falhas parciais, que continuam existindo e são ignoradas.
Buscando um modelo unificado Alternativa 2:
Projetar todas as interfaces como se a fossem remotas;
Um sistema que usa esse modelo se comporta deterministicamente em relação a falhas totais e parciais;
No entanto, assumimos uma semântica desnecessária para sistemas locais.
Isso vai de encontro ao propósito inicial.
Concorrência Apresenta o mesmo problema visto em
relação a falhas; Um objeto remoto precisa tratar execução
concorrente de métodos; Temos duas escolhas:
Ignorar concorrência, implementar todos os objetos como locais e torcer pra que tudo dê certo;
Implementar suporte a concorrência em todos os objetos, sejam eles locais ou remotos.
O mito da qualidade de serviço
Minhaaplicação
Outraaplicação
O mito da qualidade de serviço
A menos que exista uma operação de lock para o contexto, não se pode fazer esse código robusto.
Lições do NFS Exemplo de API não distribuída (open,
read, write, close) que foi re-implementada para sistemas distribuídos;
Antes do NFS, sistemas de arquivos indicavam erros raros (disco cheio ou disco inutilizável): Em geral, resultavam em falha total;
O NFS introduziu o conceito de falha parcial em um sistema de arquivos.
Lições do NFS Mais uma vez, duas alternativas;
Soft mount: expõe as falhas para a aplicação do usuário; A aplicação cliente tem que estar preparada
para receber tais falhas. Caso contrário, a aplicação cliente pode
corromper o sistema de arquivos; Hard mount:
A aplicação fica suspensa (“congela”) até que o servidor volte;
Lições do NFS Não existe maneira de eliminar hard-
mounting sem modificar a interface (não depende somente de implementação);
NFS é uma aplicação de sucesso (usando hard-mounting), mas possui limitações de escalabilidade devido à escolha de não mudar as interfaces.
É preciso que haja um administrador de sistema que identifique a falha e inicie um procedimento de recuperação.
O caminho das pedras... (Conclusões) Deve-se levar a sério as diferenças entre
comunicação local e remota; Unificação dos modelos gera um trade-off:
Modelo semelhante ao local, mas pouco robusto para aplicações distribuídas;
Modelo distribuído, muito complexo e desnecessário para programação local;
É importante ter consciência das diferenças e usar um modelo próprio para o tipo de aplicação distribuída;
O caminho das pedras... Tais diferenças devem ser levadas em
consideração em todos os estágios de projeto e implementação;
Uma linguagem que deixa bem clara a diferença entre programação local e distribuída ajuda o programador a ter essas diferenças sempre em mente;
Podemos manter IDLs para descrever objetos, mas precisamos definir explicitamente quando um objeto é remoto;
O caminho das pedras... A interface de um objeto remoto precisa
prover meios de lidar com falhas (detecção e recuperação);
O compilador da linguagem de programação deve ser “inteligente” ao gerar código para objetos locais e remotos;
Ao desenvolver código, o programador tem que estar ciente se está se comunicando com um objeto local ou remoto;
O caminho das pedras... O programador tem que pensar no
problema de maneira diferente do que seria o problema local;
Dessa forma, ao invés de perder tempo tentando unificar os modelos local e distribuído, os esforços devem ser direcionados para melhorar a performance e robustez de ambos os modelos.
Top Related