sistemas distribuídos - aula 02
Post on 17-Dec-2014
291 Views
Preview:
DESCRIPTION
TRANSCRIPT
1
SISTEMAS DISTRIBUÍDOS
MODELOS DE SISTEMA
ARTHUR EMANUEL DE OLIVEIRA CAROSIA
2
INTRODUÇÃO
3
INTRODUÇÃO
Um modelo de arquitetura de um sistema distribuído:
• Define a forma pelo qual os componentes do sistema:
• interagem;
4
INTRODUÇÃO
Um modelo de arquitetura de um sistema distribuído:
• Define a forma pelo qual os componentes do sistema:
• interagem; • são mapeados em uma rede de computadores.
5
INTRODUÇÃO
Um modelo de arquitetura de um sistema distribuído:
• Define a forma pelo qual os componentes do sistema:
• interagem; • são mapeados em uma rede de computadores.
Exemplos incluem:
cliente-servidor
6
INTRODUÇÃO
Um modelo de arquitetura de um sistema distribuído:
• Define a forma pelo qual os componentes do sistema:
• interagem; • são mapeados em uma rede de computadores.
Exemplos incluem:
cliente-servidor
peer-to-peer.
7
CONSIDERAÇÕES
Em um sistema distribuído:
• Não existe a noção de relógio global.
Toda comunicação entre processos pode sofrer:
• atrasos;
• variedade de falhas; e
• ser vulnerável a ataques de segurança.
8
MODELOS DE ARQUITETURAS DE SISTEMAS DISTRIBUÍDOS
9
MODELOS DE ARQUITETURAS DE SISTEMAS DISTRIBUÍDOS
Deve-se considerar:
• O posicionamento dos componentes em uma rede de computadores.
• Os inter-relacionamentos entre componentes.
10
CAMADAS DE SOFTWARE
11
CAMADAS DE SOFTWARE
12
CAMADAS DE SOFTWAREPlataforma
• Camadas de hardware e software de mais baixo nível.
• Oferecem uma interface de programação do sistema a um nível que facilita a comunicação e coordenação entre processos.
13
CAMADAS DE SOFTWAREMiddleware• Camada de software cujo objetivo é mascarar a heterogeneidade e fornecer
um modelo de programação conveniente. • Implementa a comunicação e oferecendo suporte para compartilhamento de
recursos a aplicativos distribuídos. • Ex: CORBA, JAVA RMI e Web Services.
14
ARQUITETURAS DISTRIBUÍDAS
15
ARQUITETURAS DISTRIBUÍDAS• Arquitetura cliente-servidor
• Arquitetura peer-to-peer
16
ARQUITETURA CLIENTE-SERVIDOR
17
ARQUITETURA CLIENTE-SERVIDOR• Arquitetura mais estudada e amplamente empregada.
• Processos clientes interagem com processos servidores para acessar os recursos compartilhados que estes gerenciam.
• Existe a possibilidade de um servidor pode ser cliente de outro servidor.
18
ARQUITETURA CLIENTE-SERVIDOR
19
ARQUITETURA PEER-TO-PEER
20
ARQUITETURA PEER-TO-PEER• O modelo cliente-servidor não é flexível em termos de
escalabilidade:
• centraliza o fornecimento de serviços
Peer-to-peer
• processos desempenham funções semelhantes, interagindo cooperativamente como pares (peers)
• sem distinção entre processos clientes e servidores.
O padrão de comunicação entre os peers depende do que do objetivo da aplicação.
21
ARQUITETURA PEER-TO-PEER
22
REQUISITOS DE PROJETOS PARA ARQUITETURAS DISTRIBUÍDAS
23
REQUISITOS DE PROJETOS PARA ARQUITETURAS DISTRIBUÍDAS• O compartilhamento eficiente de dados em larga escala é
um importante desafio.
• Com a alteração dos dados, a possibilidade de atualizações concorrentes e conflitantes aumenta.
24
REQUISITOS DE PROJETOS PARA ARQUITETURAS DISTRIBUÍDASProblemas de desempenho
• São os desafios advindos da distribuição de recursos.
25
PROBLEMAS DE DESEMPENHO
Reatividade:
os usuários exigem resposta rápida e consistente, mas os programas clientes acessam recursos compartilhados, o que introduz atraso de processamento.
Taxa de rendimento (throughput):
velocidade com que o trabalho computacional é feito.
Balanceamento de carga computacional:
aplicativos e processos de serviço devem prosseguir concomitantemente, sem disputar os mesmos recursos.
26
PROBLEMAS DE DESEMPENHOUso de cache:
melhorar o desempenho em sistemas distribuídos no instante em que o cliente faz uma requisição a um servidor.
Tolerância a falhas:
desejável que as aplicações continuem a funcionar corretamente na presença de falhas no hardware, software e comunicação.
Segurança:
armazenamento de dados sigilosos em sistemas distribuídos está intimamente ligado com a necessidade de segurança contra ataques.
27
MODELOS FUNDAMENTAIS
Um modelo deve responder ás seguintes questões:
• Como são as principais entidades do sistema?
• Como elas interagem?
• Quais as características que afetam seu comportamento individual e coletivo?
28
MODELOS FUNDAMENTAIS• Modelo de interação;
• Modelo de falha;
• Modelo de segurança;
29
MODELO DE INTERAÇÃO
Interação entre processos ocorre com o uso de troca de mensagens.
O modelo de interação deve considerar que ocorrem atrasos e isso pode limitar a coordenação dos processos.
Envio de mensagens Síncrono vs Assíncrono
30
MODELO DE INTERAÇÃO
Sistema Distribuído Síncrono
• Tempo de cada etapa de um processo tem valores conhecidos;
• Mensagens: são recebidas dentro de um tempo limitado, conhecido;
• Relógio local: taxa de desvio do tempo real conhecido.
Sistema cujas restrições são difíceis de atingir.
Serve para simplificar a modelagem de um sistema real.
:
31
MODELO DE INTERAÇÃO
Sistema Distribuído Assíncrono:
Não possui considerações sobre:
• Velocidades de execução dos processos.
• Atrasos na transmissão das mensagens.
• Taxas de desvio do relógio.
Difícil determinar a ordenação dos eventos em um sistema real.
32
MODELO DE INTERAÇÃOSistema Distribuído Assíncrono
Exemplo: sistema de troca de mensagens
33
MODELO DE INTERAÇÃOSistema Distribuído Assíncrono
Exemplo: sistema de troca de mensagens
34
MODELO DE FALHAS
A operação correta de um sistema distribuído é ameaçada quando ocorre uma falha em qualquer um dos computadores que ele é executado ou na rede que os interliga.
O modelo de falhas define e classifica as falhas para que os sistemas projetados sejam capazes de:
• tolerar certos tipos de falhas e • continuar funcionando corretamente.
35
MODELO DE FALHAS
É possível construir serviços confiáveis a partir de componentes que exibem falhas.
O conhecimento das características da falha de um componente pode permitir que um novo serviço seja projetado de forma a mascarar a falha dos componentes dos quais depende.
36
MODELO DE FALHAS
Falha por omissão de processo:
Acontece quando o processo entra em colapso, parando e não executando o outro passo de seu programa.
Indicador:
Timeout
37
MODELO DE FALHAS
Falha por omissão de processo
Sistema assíncrono:
• o processo pode ter entrado em colapso;• estar lento;• as mensagens podem não ter chegado;
Sistema síncrono
• processos deixaram de responder a mensagens sabidamente entregues.
38
MODELO DE FALHAS
Na falha de omissão por comunicação
Canal de comunicação não concretiza a transferência de uma mensagem do buffer de envio de para o buffer de recepção.
• Falta de espaço no buffer de recepção
• Perda de mensagens
39
MODELO DE SEGURANÇA
A natureza modular dos sistemas distribuídos os expõe a ataques de agentes externos e internos.
O modelo de segurança define e classifica as formas que os ataques podem assumir, dando uma base para a análise de possíveis ameaças a um sistema e guiar o desenvolvimento de sistemas capazes de resistir a eles.
40
MODELO DE SEGURANÇA
Precisam de segurança:
• Processos• Vulnerabilidades
• Canais usados para envio de mensagens• Sniffers
• Objetos que podem ser acessados remotamente• Uso não autorizado
41
MODELO DE SEGURANÇA
42
MODELO DE SEGURANÇA
Processos interagem trocando mensagens
• as mensagens ficam expostas a ataques na rede.
Invasor
• atacante capaz de enviar mensagem para qualquer processo e ler ou copiar qualquer mensagem entre dois processos.
43
MODELO DE SEGURANÇAOs ataques podem ser realizados por um computador conectado a uma rede para executar um programa que lê as mensagens ou por programas que gerem mensagens que façam falsos pedidos para serviços e deem a entender que sejam provenientes de usuários autorizados.
44
SISTEMAS DISTRIBUÍDOS
MODELOS DE SISTEMA
ARTHUR EMANUEL DE OLIVEIRA CAROSIA
top related