Projeto de Sistemas Distribuídos Prof João Paulo A Almeida (@infufesbr) Projeto de Sistemas Distribuídos Até agora consideramos apenas a infraestrutura para a construção de aplicações distribuídas (middleware) Já vimos um exemplo de sistema distribuído construído com middleware: Servidor de nomes Na aula de hoje, vamos considerar o projeto de sistemas: Arquiteturas possíveis Critérios a serem usados Inclui slides de Instructor s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn 4 Importantes decisões arquiteturais 1 Divisão de responsabilidades entre partes (componentes) do sistema Arquitetura e-servidor Básica A divisão de responsabilidades entre cliente e servidor já conhecemos em parte (orientação a objetos) Instructor s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn 4 Arquitetura e-servidor Básica Arquitetura e-servidor Generalizada A divisão de responsabilidades entre cliente e servidor já conhecemos em parte (orientação a objetos) Linhas de execução De partes diferentes são em geral independentes Instructor s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn 4 Instructor s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn 4 1
Arquitetura e-servidor Generalizada com identificação de tiers Arquitetura e-servidor Generalizada com identificação de tiers Apresentação (interação com usuário) Lógica de Sessão Banco de dados Requisições a um serviço Acesso ao serviço Recursos (dados, computacionais) Instructor s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn 4 Instructor s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn 4 Arquitetura e-servidor Básica Temos que considerar também a localização dos objetos Por que? Flexibilidade na Localização de objetos Porque o middleware nos permite definir a aplicação independemente da localização dos objetos, podemos postergar algumas decisões sobre a localização dos objetos Não precisamos necessariamente definir completamente a localização dos objetos em tempo de projeto A divisão de responsabilidade entre as partes do sistema nos leva a uma definição de sistema com potencial de distribuição Um sistema distributível Centralizado x distributível x distribuído Instructor s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn 4 Arquitetura e-servidor Generalizada Arquitetura e-servidor Generalizada Instructor s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn 4 Instructor s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn 4 2
Arquitetura e-servidor Generalizada e e m1 m2 Instructor s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn 4 e e m1 m2 m1 m2 Decisões arquiteturais importantes e m1 m2 e 1 Divisão de responsabilidades entre partes (componentes) do sistema 2 Localização dos componentes do sistema 3 Relação entre 1 e 2: Em que momento(s) definiremos localização (em que momento faremos alocação) Como o potencial de localização afeta as propriedades do sistema 3
Alocação de componentes (distribuição) Em que momento(s) definiremos localização: estático dinâmico Tempo de Projeto (design time) Tempo de Instalação (deployment time) Tempo de Configuração Tempo de Execução (runtime) Definido pelo desenvolvedor X Definido pelo sistema/middleware Distribuição e as propriedades do sistema Propriedades visíveis externamente: Desempenho no tempo: tempo de resposta, capacidade, vazão Confiabilidade e Disponibilidade Escalabilidade Segurança Possibilidade de evolução Características internas: Grau de concorrência/paralelismo e aceleração Custo de comunicação (via rede) Compartilhamento de recursos (memória, disco) Eficiência Carga em nós de processamento Arquitetura com replicação Com que finalidade? Service Arquitetura com replicação Aumentar disponibilidade Diminuir tempo de resposta Aumentar vazão total/capacidade Service Como? Requer sincronização dos estados dos objetos Arquitetura com replicação Service Arquitetura com proxies para caching e balanceamento de carga Faz sentido? Proxy Requer sincronização dos estados dos objetos 4
Arquitetura com proxies para caching e balanceamento de carga Arquiteturas peer-to-peer Peer 2 Peer 1 Proxy Sharable objects Peer 3 Considerar custo de comunicação E ganhos de escala (números de requisições idênticas) Normalmente requer tolerância à inconsistência de cache Peers 5 N Peer 4 Exemplo de Arquitetura: e/servidor com e s Exemplo de Arquitetura: e/servidor com e s delega tarefas para escravos e e e Diminuir tempo de resposta Diminuir tempo de resposta Exemplo de Arquitetura: e/servidor com e s e Projeto detalhado Modelos de linhas de execução Definição de interfaces Estratégia de publicação de referências Estratégias de detecção e tolerância a falhas e 5
Exemplo de Arquitetura: e/servidor com e s deve atender diversos clientes simultaneamente e e não pode bloquear esperando respostas Mesmo que saibamos como alocar os objetos, devemos saber como alocar tarefas 6