Sistemas Distribuídos Introdução

Apresentação em tema: "Sistemas Distribuídos Introdução"— Transcrição da apresentação:

1 Sistemas Distribuídos Introdução
Especialização em Redes de Computadores Prof. Fábio M. Costa Instituto de Informática - UFG

2 Conteúdo O que é um sistema distribuído?
Exemplos de sistemas distribuídos Requisitos de sistemas distribuídos Transparência em sistemas distribuídos Baseado em Emmerich, 2000 Prof. Fábio M. Costa

3 O que é um Sistema Distribuído?
Baseado em Emmerich, 2000 Prof. Fábio M. Costa

4 O que é um Sistema Distribuído?
Component1 Componentn Hostn-1 Hostn Host2 Host1 Middleware Network Operating System Hardware Network Baseado em Emmerich, 2000 Prof. Fábio M. Costa

5 O que é um Sistema Distribuído?
Um sistema distribuído é uma coleção de hosts autônomos, conectados através de uma rede de computadores. Cada host executa componentes e opera um middleware de distribuição, o qual habilita os componentes a coordenarem suas atividades de tal forma que usuários percebam o sistema como um ambiente computacional único e integrado. Baseado em Emmerich, 2000 Prof. Fábio M. Costa

6 Exemplos de Middleware
Orientados a Transações IBM CICS BEA Tuxedo IBM Encina Microsoft Transaction Server Orientados a Mensagens Microsoft Message Queue NCR TopEnd Sun Tooltalk Procedural Sun ONC Linux RPCs OSF DCE Orientado a Objetos OMG CORBA Sun Java/RMI Microsoft COM Sun Enterprise Java Beans Baseado em Emmerich, 2000 Prof. Fábio M. Costa

7 Características de Sistemas Centralizados
Um componente, com partes não autônomas Componentes são compartilhados por todos os usuários durante todo o tempo Todos os recursos acessíveis (tipicamente) Software ‘roda’ em um único processo Ponto de controle único Ponto de falha único Baseado em Emmerich, 2000 Prof. Fábio M. Costa

8 Características de Sistemas Distribuídos
Múltiplos componentes autônomos Componentes não são compartilhados por todos os usuários Recursos podem não ser acessíveis Software ‘roda’ em processos concorrentes e em processadores distintos Múltiplos pontos de controle Múltiplos pontos de falha (!!!) Baseado em Emmerich, 2000 Prof. Fábio M. Costa

9 Exemplos de Sistemas Distribuídos
Baseado em Emmerich, 2000 Prof. Fábio M. Costa

10 Motivação Estudos de caso
Sistema de video-sob-demanda (Hongkong Telecom) Infra-estrutura de informática (setor bancário) Sistema de gerenciamento de configurações de aeronaves (Boeing) Sistema de gerência de federação de futebol Desenvolvidos empregando os princípios e técnicas apresentados neste curso Servem como exemplos ilustrativos para o curso Baseado em Emmerich, 2000 Prof. Fábio M. Costa

11 Ex.1: Sistema de Vídeo-sob-Demanda
… Objetivo: prover aos assinantes facilidades para o ‘download’ de vídeos a partir de servidores para serem apresentados em Web-TVs de baixo custo Atualmente: cerca de usuários Construído utilizando tecnologia de objetos Baseado em Emmerich, 2000 Prof. Fábio M. Costa

12 Requisitos: Heterogeneidade
Hardware: Clientes: Web-TV Servidores: processador RISC Sistemas operacionais: Clientes: JavaOS Servidores: UNIX Linguagens de programação: Clientes: Java Servidores: C++ Baseado em Emmerich, 2000 Prof. Fábio M. Costa

13 Requisitos (cont.) Comunicação através da rede Escala Segurança
Como transmitir estruturas de dados complexas através da Internet? Escala Expansão para um grande número de usuários Segurança Forma segura de pagamento Autenticação e controle de acesso Baseado em Emmerich, 2000 Prof. Fábio M. Costa

14 Por que Tecnologias de Objetos Distribuídos?
Distribuição: Clientes de vídeo necessitam fazer o ‘download’ / exibição de vídeo na Web-TV do usuário final Múltiplos servidores (balanceamento de carga) Tecnologia de objetos: Clientes de vídeo escritos em Java: Web-TV contém um Máquina Virtual Java Portabilidade - ex: Sony Playstation, Sega Console Servidores de vídeo escritos em C++: desempenho Baseado em Emmerich, 2000 Prof. Fábio M. Costa

15 Por que Tecnologias de Objetos Distribuídos? (cont.)
Uma maneira natural de particionar a funcionalidade de uma aplicação ou sistema Objetos: unidades funcionais autônomas que se comunicam entre si através da troca de mensagens Abstração ideal para a construção de sistemas distribuídos Objetos diferentes podem ser instalados em computadores distintos Cooperação através de mensagens transmitidas pela rede Baseado em Emmerich, 2000 Prof. Fábio M. Costa

16 Ex.2: Infra-estrutura de Informática Empresarial (Setor Bancário)
Serviço de Informações de Clientes Serviços de Autorização Estação de Negócios Serviço de Banco de Dados de Produtos Serviços de Marketing Baseado em Emmerich, 2000 Prof. Fábio M. Costa Serviços em Mainframes

17 Requisitos Tempo para se chegar ao mercado Escalabilidade
Desenvolvimento de novas aplicações com tecnologia recente Integração de novas aplicações tem se tornado cada vez mais difícil Escalabilidade Administração de milhões de contas e clientes Milhares de usuários concorrentes Confiabilidade Baseado em Emmerich, 2000 Prof. Fábio M. Costa

18 Requisitos (cont.) Heterogeneidade de Hardware
Mainframes (Unisys, IBM, etc.) Servidores SUN SPARC PCs Heterogeneidade de Sistema Operacional MVS, UNIX, Linux, Windows Heterogeneidade de Linguagem de Programação Cobol, C/C++, Visual Basic, Java Baseado em Emmerich, 2000 Prof. Fábio M. Costa

19 Por que Tecnologia de Objetos Distribuídos
Permite uma visão uniforme de todos os serviços da empresa e de como acessá-los Provê um nível apropriado de abstração Preserva o investimento encapsulando aplicações legadas Permite explorar as vantagens da tecnologia de objetos em novos projetos Uma forma natural de resolver: distribuição heterogeneidade Baseado em Emmerich, 2000 Prof. Fábio M. Costa

20 Ex.3: Gerência de Configuração Boeing 777
Baseado em Emmerich, 2000 Prof. Fábio M. Costa

21 Problemas a serem resolvidos
Escala de peças por aeronave A configuração de cada aeronave é diferente Regulamentos demandam que registros sejam mantidos para cada peça de uma aeronave Aeronave evolui durante manutenções Produção de 500 aeronaves por ano Banco de dados de configuração cresce 1,5 bilhão de partes a cada ano Tempo de vida de uma aeronave: 30 anos engenheiros necessitam acesso on-line aos dados de configurações Baseado em Emmerich, 2000 Prof. Fábio M. Costa

22 Problemas a serem resolvidos (cont.)
Integração de componentes de prateleira Infra-estrutura de TI se tornou inadequada Mas a empresa não podia se dar ao luxo de re-construir toda a sua infra-estrutura de TI Componentes foram comprados de diversos fabricantes especializados Banco de dados relacional Planejamento de recursos da empresa (ERP) Planejamento de projetos auxiliado por computador Componentes precisavam ser integrados Baseado em Emmerich, 2000 Prof. Fábio M. Costa

23 Problemas a serem resolvidos (cont.)
Heterogeneidade 20 máquinas de banco de dados Sequent para gerenciar os dados de configuração de aviões 200 servidores de applicações UNIX Estações de trabalho NT e UNIX para os engenheiros Baseado em Emmerich, 2000 Prof. Fábio M. Costa

24 Por que Tecnologia de Objetos Distribuídos
Componentes de prateleira encapsulam a funcionalidade da aplicação Resolvendo o problema de distribuição em um nível mais elevado de abstração Resolvendo o problema da heterogeneidade Escalabilidade da solução Baseado em Emmerich, 2000 Prof. Fábio M. Costa

25 Ex.4: Administração de uma Federação de Futebol
Administração de campeonatos, seleção nacional, clubes, transferência de jogadores, etc. Sistema imaginário Exemplo comum, que pode ser ajustado com finalidade didática Baseado em Emmerich, 2000 Prof. Fábio M. Costa

26 Requisitos Autonomia dos clubes Necessidade de integração para:
Cada clube opera sua própria administração, treinamento, escala de jogos e jogadores, etc. Necessidade de integração para: o registro de jogadores na federação de futebol requisitar jogadores para a seleção nacional combinar a escala de jogos do campeonato Heterogeneidade Diferentes máquinas (Windows, Linux, etc.) Diferentes linguagens de programação Baseado em Emmerich, 2000 Prof. Fábio M. Costa

27 Requisitos de Sistemas Distribuídos

28 Requisitos Gerais Integração de componentes Heterogeneidade
Componentes novos, implementados com a mais moderna tecnologia Componentes de prateleira (COTS), que não podem ser modificados Componentes legados, sem a necessidade de uma re-engenharia Heterogeneidade Plataformas de hardware, sistemas operacionais, linguagens de programação e redes Baseado em Emmerich, 2000 Prof. Fábio M. Costa

29 Qual o objetivo da construção de um sistema distribuído?
Requisitos Comuns Qual o objetivo da construção de um sistema distribuído? Compartilhamento de Recursos Abertura Concorrência Escalabilidade Tolerância a Falhas Transparência Baseado em Emmerich, 2000 Prof. Fábio M. Costa

30 Compartilhamento de Recursos
Habilidade de usar qualquer hardware, software ou dados em qualquer lugar do sistema Gerenciador de recursos Controla o acesso aos recursos Provê um esquema de nomes para os recursos Controla acessos concorrentes aos recursos Baseado em Emmerich, 2000 Prof. Fábio M. Costa

31 Compartilhamento de Recursos (2)
Modelo de compartilhamento Cliente / Servidor Baseado em objetos Define: a forma pela qual recursos são providos formas de uso dos recursos como o provedor do recurso e os usuários interagem entre si e com o gerenciador Baseado em Emmerich, 2000 Prof. Fábio M. Costa

32 Abertura Relacionada com futuras extensões e melhorias que um sistema distribuído pode sofrer Novos componentes precisam ser integrados, juntamente com componentes existentes (legados) Provenientes de diversas fontes Usando diferentes tecnologias Necessário publicar interfaces detalhadas dos componentes Diferenças de representação de dados precisam ser resolvidas (para uma troca de informações efetiva) Baseado em Emmerich, 2000 Prof. Fábio M. Costa

33 Concorrência Em um sistema distribuído, componentes são executados em paralelo Em processos ou máquinas diferentes Componentes acessam e atualizam recursos compartilhados (variáveis, bancos de dados) A integridade do sistema pode ser violada se atualizações concorrences não forem coordenadas Atualizações podem ser perdidas (sobrescritas) Análise de dados pode ficar inconsistente Baseado em Emmerich, 2000 Prof. Fábio M. Costa

34 Componentes devem ser projetados para serem escaláveis
Escalabilidade Adaptação de sistemas distribuídos para Acomodar mais usuários Obter um tempo de resposta mais rápido Usualmente através da adição de mais processadores Componentes não devem necessitar ser alterados quando a escala do sistema cresce Componentes devem ser projetados para serem escaláveis Baseado em Emmerich, 2000 Prof. Fábio M. Costa

35 Tolerância a Falhas Hardware, software e redes podem falhar!
Um sistema distribuído deve manter sua disponibilidade mesmo em baixos níveis de confiabilidade do hardware/software/rede Tolerância a falhas pode ser obtida com: técnicas de recuperação redundância Baseado em Emmerich, 2000 Prof. Fábio M. Costa

36 Transparência em Sistemas Distribuídos

37 Transparência Um sistema distribuído deve ser percebido por seus usuários e pelos programadores de aplicações como um sistema único e coeso ao invés de uma coleção de máquinas separadas Várias dimensões de transparência identificadas pelo modelo ISO RM-ODP Modelo de Referência para Sistemas Distribuídos Abertos Representam as diversas propriedades que um sistema distribuído deve possuir Baseado em Emmerich, 2000 Prof. Fábio M. Costa

38 Transparências de Distribuição
Scalability Transparency Performance Transparency Failure Transparency Migration Transparency Replication Transparency Concurrency Transparency Access Transparency Location Transparency Baseado em Emmerich, 2000 Prof. Fábio M. Costa

39 Transparência de Acesso
Permite que objetos e informações remotas sejam acessados usando operações idênticas Mascara as diferentes formas de acesso empregadas por cada tecnologia utilizada Exemplos: Operações de acesso a um sistema de arquivos distribuído com NFS (Network File System) Navegação na WEB Consultas em SQL Baseado em Emmerich, 2000 Prof. Fábio M. Costa

40 Transparência de Localização
Permite que objetos e informações sejam acessados sem o conhecimento de sua localização Exemplos: Arquivos acessados via NFS Páginas na WEB (*) Tabelas em um banco de dados distribuído Baseado em Emmerich, 2000 Prof. Fábio M. Costa

41 Transparência de Concorrência
Permite que vários processos operem concorrentemente usando objetos de informação compartilhados sem interferirem entre si Exemplos: NFS Caixa eletrônico Sistema gerenciador de bancos de dados (SGBD) Baseado em Emmerich, 2000 Prof. Fábio M. Costa

42 Transparência de Replicação
Permite que múltiplas instâncias de objetos de informação sejam usados para melhorar o desempenho e a confiabilidade Sem que os usuários ou programadores de aplicações tomem conhecimento da existência das réplicas Exemplos: SGBD distribuído Espelhamento de páginas WEB Baseado em Emmerich, 2000 Prof. Fábio M. Costa

43 Transparência de Falhas
Mascara a ocorrência de falhas Permite que usuários e aplicações completem suas tarefas normalmente a despeito de falhas em alguns componentes do sistema Exemplo: Transações em um SGBD Baseado em Emmerich, 2000 Prof. Fábio M. Costa

44 Transparência de Migração
Permite a movimentação de um objeto dentro do sistema distribuído sem afetar as operações dos usuários ou dos programas de aplicação Duas variantes: Migração propriamente dita: com relação ao objeto migrado Relocação: com relação a outros objetos no sistema Exemplos: NFS Páginas WEB Baseado em Emmerich, 2000 Prof. Fábio M. Costa

45 Transparência de Desempenho
Permite que o sistema distribuído seja reconfigurado para melhorar o desempenho para refletir mudanças na carga de processamento Através de replicação e migração Exemplo: Utilitário make distribuído Programa é compilado em várias máquinas em paralelo, transparentemente para o usuário Baseado em Emmerich, 2000 Prof. Fábio M. Costa

46 Transparência de Escala
Permite que o sistema e as aplicações possam ser expandidos em escala sem a necessidade de mudanças em sua estrutura ou nos algoritmos utilizados Exemplo: WWW Bancos de dados distribuídos Baseado em Emmerich, 2000 Prof. Fábio M. Costa

47 Pontos-Chave O que é um Sistema Distribuído
Adoção de sistemas distribuídos é regida por requisitos não-funcionais Necessidades de distribuição são transparentes aos usuários e projetistas de aplicações Várias dimensões de transparência Dimensões de transparência dependem entre si Baseado em Emmerich, 2000 Prof. Fábio M. Costa