Sistemas Distribuídos
Introdução
Especialização em Redes de
Computadores
Prof. Fábio M. Costa
Instituto de Informática - UFG
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
2
O que é um Sistema
Distribuído?
Baseado em Emmerich, 2000
Prof. Fábio M. Costa
3
O que é um Sistema
Distribuído?
Component1
Componentn
Middleware
Network Operating System
Hardware
Component1
Componentn
Middleware
Network Operating System
Hardware
Hostn-1
Host2
Component1
Componentn
Middleware
Network Operating System
Hardware
Host1
Baseado em Emmerich, 2000
Network
Component1
Componentn
Middleware
Network Operating System
Hardware
Prof. Fábio M. Costa
Hostn
4
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
5
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
Baseado em Emmerich, 2000
• Procedural
– Sun ONC
– Linux RPCs
– OSF DCE
• Orientado a Objetos
– OMG CORBA
– Sun Java/RMI
– Microsoft COM
– Sun Enterprise Java
Beans
Prof. Fábio M. Costa
6
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
7
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
8
Exemplos de Sistemas
Distribuídos
Baseado em Emmerich, 2000
Prof. Fábio M. Costa
9
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
10
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 100.000 usuários
• Construído utilizando tecnologia de objetos
Baseado em Emmerich, 2000
Prof. Fábio M. Costa
11
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
12
Requisitos (cont.)
• Comunicação através da rede
– 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
13
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
14
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
15
Ex.2: Infra-estrutura de Informática
Empresarial (Setor Bancário)
Serviço de
Informações
de Clientes
Serviço de Banco
de Dados de Produtos
Serviços de
Marketing
Baseado em Emmerich, 2000
Serviços de
Autorização
Estação de
Negócios
Prof. Fábio M. Costa
Serviços
em Mainframes
16
Requisitos
• Tempo para se chegar ao mercado
– 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
17
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
18
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
19
Ex.3: Gerência de Configuração
Boeing 777
Baseado em Emmerich, 2000
Prof. Fábio M. Costa
20
Problemas a serem resolvidos
• Escala
– 3.000.000 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
– 45.000 engenheiros necessitam acesso on-line aos
dados de configurações
Baseado em Emmerich, 2000
Prof. Fábio M. Costa
21
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 reconstruir 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
22
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
23
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
24
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
25
Requisitos
• Autonomia dos clubes
– 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
26
Requisitos de Sistemas
Distribuídos
Requisitos Gerais
• Integração de componentes
– 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
28
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
29
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
30
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
31
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
32
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
33
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
34
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
35
Transparência em
Sistemas Distribuídos
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
37
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
38
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
39
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
40
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
41
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
42
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
43
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
44
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
45
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
46
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
47