2 - modelos e arquitecturas -2014 - tagus [modo de...
TRANSCRIPT
1
Departamento de Engenharia Informática
Sistemas Distribuídos
Revisão de redes
Modelos e arquitecturas
13/14 Sistemas Distribuídos 1
Departamento de Engenharia Informática
A rede que interliga o
sistema distribuído
Revisão
13/14 Sistemas Distribuídos 2
2
Departamento de Engenharia Informática
Programação da comunicação: modelo
Processo Canal de comunicação
portoProcesso
API da
comunicação
modo utilizador modo sistema
rede
porto
transport
e
rede
lógic
o
físic
o
13/14 Sistemas Distribuídos 3
Departamento de Engenharia Informática
Redes de Dados
• Fornecer uma base mínima de compreensão das redes de dados
– Arquitectura
– Organização
– Protocolos
• Identificar os aspectos relevantes das redes de dados na concepção de sistemas distribuídos
Revisão
13/14 Sistemas Distribuídos 4
3
Departamento de Engenharia Informática
Arquitectura Lógica
• Porquê uma arquitectura Lógica nas redes?
• A arquitectura lógica define as propriedades da rede, adequadas ao seu campo de aplicações
– Tipo de endereçamento
– Desempenho
– Garantia de entrega de mensagens
– Ordenação das mensagens
– Tolerância a faltas
– Endereçamento em difusão
– …
• A mesma arquitectura lógica pode ser realizada (com maior ou menor facilidade) sobre várias arquitecturas físicas
13/14 Sistemas Distribuídos 5
Departamento de Engenharia Informática
Características habituais das Arquitecturas Físicas
•Redes de Larga Escala–Transmissão ponto a ponto
–Banda passante com limitações mas tecnologias tradicionais
–Topologia malhada com redundância
–Necessidade de encaminhamento
–Grande escalabilidade
–Menor tolerância a faltas
•Redes Locais–Transmissão em difusão–Largura de Banda muito grande–Topologias de bus ou anel–Encaminhamento trivial–Menor escalabilidade–Maior tolerância a faltas
13/14 Sistemas Distribuídos 6
4
Departamento de Engenharia Informática
Modelo de Referência
• Um Modelo de Referência, ou Família de Protocolos, define as características lógicas e físicas das redes• Normalmente divididos em níveis
• Os níveis são independentes mas estão relacionados
• Permitem várias realizações compatíveis
• cada nível corresponde a um nível de abstração necessário no modelo
• cada nível possui funções próprias e bem definidas• as funções de cada nível foram escolhidas segundo a definição dos protocolos
normalizados internacionalmente
• as fronteiras entre níveis devem ser definidas de modo a minimizar o fluxo de informação nas interfaces
• o número de níveis deve ser suficientemente grande para que funções distintas não precisem ser colocadas na mesma nível • e, ao mesmo tempo, suficientemente pequeno que não torne a arquitectura
difícil de controlar.
13/14 Sistemas Distribuídos 7
Departamento de Engenharia Informática
• Funções: conseguir transmitir 1 bit de informação sobre meio físico de interligação
– Velocidade de propagação, atenuação, imunidade ao ruído, etc.
• Nível Físico define:– Níveis eléctricos do sinal, características
temporais
– Protocolos de codificação, baseados no funcionamento da rede (taxa de erros, recuperação de relógio, …)
– Placas de interface (network cards)• Interface eléctrica
• Aspectos mecânicos dos conectoresBus
Anel (ring)
Malha (mesh)
OSI - Nível Físico
13/14 Sistemas Distribuídos 8
5
Departamento de Engenharia Informática
• Funções: transmissão de pacotes, ou tramas, entre máquinas ligadas à mesma rede física
• Nível Lógico define:– Delimitadores de trama
– Endereço físico do destinatário
– Multiplexagem do meio de transmissão (emissor)
– Detecção do endereço do destinatário (receptor)
– Definição da unidade básica de informação (bit, octeto)
– Recuperação de erros de transmissão
– Controlo de fluxo
Ethernet
ATMFrame
Relay
GPRS
UMTS
OSI - Nível Lógico ou
Ligação de Dados
13/14 Sistemas Distribuídos 9
Departamento de Engenharia Informática
OSI - Nível Rede
• Funções: interligar máquinas independentemente da rede física a que estão ligadas
• Uma rede lógica passa a ser composta pela interligação de várias redes físicas
• Nível Rede define:– Formato dos pacotes de dados
– Mecanismos de encaminhamento entre redes• Fundamental para redes malhadas
• Normalmente baseados em tabelas de encaminhamento
– Protocolo de rede OSI: X.25• Com ligação, sequencialidade, controlo de fluxo
– Protocolo de rede Internet: IP• Sem ligação nem garantias de qualidade
Rede IP
13/14 Sistemas Distribuídos 10
6
Departamento de Engenharia Informática
• Funções: oferecer um serviço de transmissão de informação que permita a comunicação entre utilizadores finais
• Características– Com ou sem ligação
– Comunicação fiável• Garantia de entrega
• Garantia de ordem
– Segmentação
– Controlo de fluxo
– Notificação de excepções na comunicação
Nível TransporteRede TCP
Processo Utilizador
Processo Utilizador
13/14 Sistemas Distribuídos 11
Departamento de Engenharia Informática
A Internet como um Relógio de Areia
IP
TCP / UDP
Ethernet GPRS 802.11 BluetoothSatélite
Web Audio VoIP Web ServicesMail Video IM
Difícil de alterarPassível de alterações
Maior inovação
13/14 Sistemas Distribuídos 12
7
Departamento de Engenharia Informática
Interfaces de Comunicação
• Interacção baseada na troca de mensagens • Facilidade de transporte para múltiplos sistemas
• Exploração das APIs normais de comunicação• Tipicamente da API de transporte (sockets)
• Cada aplicação possui um protocolo próprio
• Dificulta a utilização do protocolo por terceiros
• Desempenho porque é executado em modo utilizador
• telnet, rlogin, Winrdp-aplicações de terminal remoto
• ftp, samba – Transferência de ficheiros
• SMTP – Correio electrónico
Exemplos Problemas?
13/14 Sistemas Distribuídos 13
Departamento de Engenharia Informática
Interfaces de Comunicação
Máquina A
OS kernel
Níveis7 a 5
Sockets, TLI
Níveis3 a 1Níveis3 a 1
Máquina B
OS kernel
Níveis7 a 5
aplicação
Sockets, TLI
Níveis3 a 1
Níveis3 a 1
aplicação
Nível 4TransporteNível 4Transporte
Nível 4TransporteNível 4Transporte
13/14 Sistemas Distribuídos 14
8
Departamento de Engenharia Informática
Caracterização do canal de Comunicação
• Com ligação
– Normalmente serve 2 interlocutores
– Normalmente fiável, bidireccional e garante sequencialidade
• Sem ligação
– Normalmente serve mais de 2 interlocutores
– Normalmente não fiável: perdas, duplicação, reordenação
• Canal com capacidade de armazenamento em fila de Mensagens
– Normalmente com entrega fiável das mensagens
Tipos de canais
13/14 Sistemas Distribuídos 15
Departamento de Engenharia Informática
Portos – Extermidades do Canal de
Comunicação
• Portos– São extremidades de canais de comunicação
• Em cada máquina são representados por objectos do modelo computacional local
– Possuem 2 tipos de identificadores:• O do objecto do modelo computacional
– Para ser usado na API pelos processos locais
– Ex.: File descriptors, handles
• O do protocolo de transporte– Para identificar a extremidade entre processos (ou
máquinas) diferentes
– Ex.: Endereços TCP/IP, URL
13/14 Sistemas Distribuídos 16
9
Departamento de Engenharia Informática
Interface sockets
• Domínio do socket: define a família de protocolos associada a um socket– INET: família de protocolos Internet
– Unix: comunicação entre processos da mesma máquina
– Outros…
• Tipo do socket: define as características do canal de comunicação– Stream: canal com ligação, bidireccional, fiável, interface tipo
sequência de octetos
– Datagram: canal sem ligação, bidireccional, não fiável, interface tipo mensagem
– Raw: permite o acesso directo aos níveis inferiores dos protocolos (ex: IP na família Internet)
13/14 Sistemas Distribuídos 18
Departamento de Engenharia Informática
Sockets sem Ligação
socket
bind
recvfrom
sendto
socket
bind
sendto
recvfrom
ClienteServidor
13/14 Sistemas Distribuídos 21
10
Departamento de Engenharia Informática
Sockets UDP em Java (Cliente)• import java.net*;
• import java.io*;
• public class UDPClient{
• public static void main(String args[]){
• // args give message contents and server hostname
• DatagramSocket aSocket = null;
• try {
• aSocket = new DatagramSocket();
• byte [] m = args [0].getBytes();
• InetAddress aHost = InetAddress.getByName(args[1]);
• Int serverPort = 6789;
• DatagramPacket request =
• new DatagramPacket(m, args[0].length(), aHost, serverPort);
• aSocket.send(request);
• byte[]buffer = new byte[1000];
• DatagramPacket reply = new DatagramPacket(buffer, buffer.length);
• aSocket.receive(reply);
• System.out.println(“Reply:” + new String(reply.getData()));
• } catch (SocketException e){System.out.println(“Socket:” + e.getMessage());
• } catch (IOException e){System.out.println(“IO:” + e.getMessage());
• } finally { if(aSocket ! = null) aSocket.close();}
• }
• }
Conversão do nome DNS para endereço IP
Constrói um socket datagram (associado a qualquer porto
disponível)
Cada mensagem enviada tem que
levar junto identificador do
processo destino: IP e porto
13/14 Sistemas Distribuídos 22
Departamento de Engenharia Informática
Sockets UDP em Java (Servidor)• import java.net*;
• import java.io*;
• public class UDPServer{
• public static void main(String args[]){
• DatagramSocket aSocket = null;
• try{
• aSocket = new DatagramSocket(6789);
• byte[] buffer = new byte [1000];
• while(true){
• DatagramPacket request = new DatagramPacket(buffer, buffer.legth);
• aSocket.receive(request);
• DatagramPacket reply = new DatagramPacket(request.getData(),
• request.getLength(); request.getAddress(), request.getPort());
• aSocket.send(reply);
• }
• } catch (SocketException e){System.outprintln(“Socket:”+ e.getMessage());
• } catch (IOException e){System.out.println(“IO:” + e.getMessage());
• } finally {if(aSocket ! = null) aSocket.close();}
• }
• }
Constrói um socket datagram (associado ao porto 6789)
Recebe mensagem
Extrai da mensagem o IP e porto do
processo origem para responder
13/14 Sistemas Distribuídos 23
11
Departamento de Engenharia Informática
Sockets com Ligação
socket
bind
listen socket
connectaccept
read
write read
write
ClienteServidor
ClienteServidor
Socket
Cliente
Socket
Escuta
Socket
Ligação
bytes
bytes
13/14 Sistemas Distribuídos 24
Departamento de Engenharia Informática
• import java.net*;
• import java.io*;
• public class TCPClient{
• public static void main(String args[]){
• // args: message and destin. hostname
• Socket s = null;
• try{
• int server Port = 7896;
• s = new Socket (args[1], serverPort);
• DataInputStream = new DataInputStream(s.getInputStream());
• DataOutputStream out =
• newDataOutputStream (s.getOutputStream());
• out.writeUTF(args[0]);
• String data = in.readUTF();
• System.out.prtintln(“Received: ” + data);
• }catch (UnknownHostException e){
• System.out.println(“Sock:” + e.getMessage());
• }catch (EOFException e){System.out.println(“EOF:”e.getMessage());
• }catch (IOException e){System.out.println(“IO:”e.getMessage());
• }finally {if(s!=null) try{s.close();}catch (IOException e}
• }
• classe Socket – suporta o socket cliente. Argumentos: nome DNS do servidor e o porto.• Construtor não só cria o socket como efectua a ligação TCP
Métodos getInputStream / getOutputStream – permitem aceder aos dois streams definidos pelo socket
WriteUTF / readUTF –para Universal transfer format / para as cadeias de caracteres
Sockets Stream em Java (Cliente)
13/14 Sistemas Distribuídos 25
12
Departamento de Engenharia Informática
• import java.net*;
• import java.io*;
• public class TCPServer{
• public static void main(String args[]){
• try{
• int server Port = 7896;
• ServerSocket listenSocket = new ServerSocket(serverPort);
• while(true){
• Socket connectionSocket = listenSocket.accept();
• myConnection c = new myConnection(connectionSocket);
• }
• }catch (IOException e){System.out.println(“Listen:”
• +e.getMessage());}
• }
• }
Bloqueia até cliente estabelecer ligação.
Cria socket servidor que fica à escuta no porto “serverPort”
Sockets Stream em Java (Servidor)
Cria novo socket servidor com quem é estabelecida ligação com o cliente e
onde os dados são recebidos
13/14 Sistemas Distribuídos 26
Departamento de Engenharia Informática
Aula prática – 1ª semana
• SocketClient.java
• SocketServer.java
13/14 Sistemas Distribuídos 27
13
Departamento de Engenharia Informática
Integração da Comunicação no Sistema
Operativo
13/14 Sistemas Distribuídos 33
Departamento de Engenharia Informática
Integração da Comunicação no Sistema
Operativo
• As aplicações invocam uma API que lhes permite aceder ao mecanismos de transporte
• A API deve ser conceptualmente independente de uma determinada pilha de protocolos de transporte
• Alternativas de implementação– Funções de ES genéricas
• Ex: sockets – parcialmente
– Funções de comunicação específicas• Ex: Algumas funções dos sockets
• Ex: TLI
– Mecanismo básico de comunicação entre processos do sistema operativo
• Ex: IPC dos micro-núcleos
13/14 Sistemas Distribuídos 34
14
Departamento de Engenharia Informática
Winsock Implementation
Application Mswsock.dll
SPI
Service Providers
NtReadFile, NtWriteFile,NtCreateFile,NTDeviceloControlFile
Kernel mode
User mode
\Device\AFD
AFD FSD
TCP/IPIPX/SPX
TDI IRPs
NetBEUI
TDI
Protocol drivers
Wshtcpip.dll
Ntdll.dll
Msafd.dll
13/14 Sistemas Distribuídos 36
Departamento de Engenharia Informática
Modelos arquitecturais
13/14 Sistemas Distribuídos 38
15
Departamento de Engenharia Informática
Aplicações
Middleware
Sistema Operativo
Bibliotecas (DLL)ProtocolosServidores
Hardware
Plataformas
Os Sistemas Distribuídos são suportados por diversas componentes frequentemente designadas por plataformas de Middleware
Pla
tafo
rm
a
s d
e
Mid
dle
ware
Camadas de Software: o Middleware
13/14 Sistemas Distribuídos 39
Departamento de Engenharia Informática
Quem são as entidades que comunicam
através da rede num sistema distribuído?
• Processos ou tarefas
• Nós
– Em alguns sistemas primitivos não existe a abstracção de
processo ou tarefa
– Exemplo: redes de sensores
• Objectos
– Exemplo: objecto Java invoca método de outro objecto remoto
– Veremos mais adiante na cadeira
• Web Services
– Veremos mais adiante na cadeira
• Componentes
– (Fora do âmbito da cadeira)
13/14 Sistemas Distribuídos 40
Por omissão, assumiremos
sistema distribuído de processos
16
Departamento de Engenharia Informática
Como comunicam estas entidades?
13/14 Sistemas Distribuídos 41
Departamento de Engenharia Informática
Est
ud
arem
os
amb
os
em b
rev
e
Comunicação directa
• Interface de comunicação entre-processos
• Invocação remota
– Protocolos de pedido-resposta
• Exemplo: HTTP
– Chamada remota de procedimentos
• Programador define conjunto de procedimentos que servidor
oferece
• Cliente pode invocar esses procedimentos como se tratassem de
chamadas locais
– Invocação remota de métodos
• Semelhante a chamada remota de procedimentos, mas no
mundo OO
13/14 Sistemas Distribuídos 42
17
Departamento de Engenharia Informática
Papéis e responsabilidades
13/14 Sistemas Distribuídos 51
Departamento de Engenharia Informática
Modelo Cliente-Servidor
• Servidores mantêm recursos e servem pedidos de operações sobre esses recursos
• Servidores podem ser clientes de outros servidores
• Simples e permite distribuir sistemas centralizados muito directamente
• Mas pouco escalável: limitado pela capacidade do servidor e pela rede que o liga aos clientes
Server
Client
Client
invocation
result
Serverinvocation
result
Process:Key:
Computer:
13/14 Sistemas Distribuídos 52
18
Departamento de Engenharia Informática
Modelo Entre-Pares (Peer-to-Peer)
• Todos os processos têm papéis semelhantes, sem distinção entre clientes e servidores
• Mais ampla distribuição de carga (computação e rede)
– Maior escalabilidade
– Sistema expande-se acrescentando mais pares
• Coordenação mais complicada que cliente-servidor
Application
Application
Application
Peer 1
Peer 2
Peer 3
Peers 5 .... N
Sharableobjects
Application
Peer 4
13/14 Sistemas Distribuídos 53
Departamento de Engenharia Informática
Entre-Pares (Peer-to-Peer)
13/14 Sistemas Distribuídos 54
19
Departamento de Engenharia Informática
Como mapear objectos e serviços no
modelo físico?
13/14 Sistemas Distribuídos 55
Departamento de Engenharia Informática
Serviço Oferecido por Múltiplos Servidores
• Distribui carga do servidor por múltiplos servidores
• Duas opções:
– Particionamento: cada servidor mantém uma partição do conjunto de objectos
– Replicação: todos os servidores mantêm réplicas do mesmo conjunto de objectos
Server
Server
Server
Service
Client
Client
13/14 Sistemas Distribuídos 56
20
Departamento de Engenharia Informática
Serviço Oferecido por Múltiplos Servidores
13/14 Sistemas Distribuídos 57
Departamento de Engenharia Informática
Servidores Proxy e Caches
• Mantêm cópias de sub-conjunto dos objectos num computador mais próximo dos clientes
• Melhor desempenho e disponibilidade
• Outros objectivos: por exemplo, acesso ao exterior através de firewall
Client
Proxy
Web
server
Web
server
serverClient
13/14 Sistemas Distribuídos 58
21
Departamento de Engenharia Informática
Servidores Proxy e Caches
13/14 Sistemas Distribuídos 59
Departamento de Engenharia Informática
Código Móvel (Applets)
• Parte do código do servidor é transferido para o cliente e executado localmente
• Execução não sofre com atrasos de rede e variações de largura de banda
• Bom desempenho de aplicações interactivas
a) client request results in the downloading of applet code
Web
server
ClientWeb
serverApplet
Applet code
Client
b) client interacts with the applet
13/14 Sistemas Distribuídos 60
22
Departamento de Engenharia Informática
Código Móvel (Applets)
13/14 Sistemas Distribuídos 61
Departamento de Engenharia Informática
Agentes móveis
• Programa em execução (código+dados) que viaja de um
computador para outro na rede
• Executa alguma tarefa em nome de alguém
• Em cada computador, invoca serviços locais (e.g. acesso
a BD local para consultar informação local)
• Comparado com a solução de ter um cliente remoto a
invocar os mesmos serviços remotamente:
– Menor custo e tempo de comunicação
13/14 Sistemas Distribuídos 62
23
Departamento de Engenharia Informática
Modelos fundamentais
13/14 Sistemas Distribuídos 63
Departamento de Engenharia Informática
Modelos fundamentais
• Explicitam quais são as entidades e características
essenciais de um sistema
• Permitem-nos:
– Generalizar o o que é possível e impossível resolver nesse
modelo (por provas matemáticas
– Desenhar soluções mais facilmente, pois não pensamos nos
detalhes de hardware, etc
– Provar matematicamente propriedades das nossas soluções
• fiabilidade, desempenho, escalabilidade, segurança
– Determinar facilmente se determinada solução funciona num
sistema em particular
• basta verificar se os pressupostos do modelo usado para a
solução se verificam no sistema em particular
13/14 Sistemas Distribuídos 64
24
Departamento de Engenharia Informática
Modelos fundamentais
• Logo, antes de desenhar qualquer solução, é
muito boa prática definir os modelos
fundamentais!
• Três modelos fundamentais:
– Modelo de interacção
– Modelo de faltas
– Modelo de segurança
13/14 Sistemas Distribuídos 65
Departamento de Engenharia Informática
Modelo de Interacção
• Pressupostos sobre o canal de comunicação?
– Latência, que inclui:
• Tempo de espera até ter acesso à rede +
• Tempo de transmissão da mensagem pela rede +
• Tempo de processamento gasto em processamento local para enviar e
receber a mensagem
– Largura de banda
• Quantidade de informação que pode ser transmitida simultaneamente
pela rede
– Jitter
• Que variação no tempo de entrega de uma mensagem é possível?
– Canal assegura ordem de mensagens?
– Mensagem pode chegar repetida?
• E sobre os relógios locais?
– Taxa com que cada relógio local se
desvia do tempo absoluto
Mais à frente no semestre, analisaremos modelos de
interacção em maior detalhe
13/14 Sistemas Distribuídos 66
25
Departamento de Engenharia Informática
Modelo de Falhas
• Que componentes podem falhar?
• De que forma podem falhar?
• Por enquanto, assumiremos modelo simples:
– Processos podem falhar silenciosamente
– Mensagens podem perder-se na rede
Mais à frente no semestre, analisaremos outros modelos de falhas em maior detalhe
13/14 Sistemas Distribuídos 67
Departamento de Engenharia Informática
Modelo de Segurança
• Que ameaças existem sobre o sistema?
• Que ataques são possíveis?
• Por enquanto, assumiremos que não existem
quaisquer ameaças sobre o sistema
Mais à frente no semestre, analisaremos modelos de segurança mais realistas
13/14 Sistemas Distribuídos 68