2 - Modelos e Arquitecturas -2013 v3.ppt [Modo de...

1

Departamento de Engenharia Informática

Sistemas Distribuídos

Revisão de redes

Modelos e arquitecturas

12/13 Sistemas Distribuídos 1


Objectivo das aulas desta semana

• Rever o modelo de arquitectura das redes

• Rever a forma de programação distribuída

baseada em mensagens (aulas práticas)

• Compreender o modelo cliente-servidor e suas

evoluções

• Perceber as limitações do modelo de

programação baseado em mensagens e a

evolução para o RPC


CaRevisão baseada nos Capitulos do livro 2, 3 e 4

2


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

Plata

formas

de

Middleware

Nova camadas de software

Middleware



A rede que interliga o

sistema distribuído

Revisão


3


Programação da comunicação: modelo

Processo Canal de comunicação

portoProcesso

API dacomunicação

modo utilizador modo sistema

rede

porto

transport

e

rede

lógic

o

físic

o



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


4


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



Modelo OSI


5


Modelo OSI

Do nível físico ao nível transporte


Bus

Anel (ring)

Malha (mesh)Ethernet

ATMFrame

Relay

GPRS

UMTS

Rede IP

Rede TCP

Processo Utilizador

Processo Utilizador


• 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


6


• 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



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


7


• 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



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


8


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?



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


9


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



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


10


Aula Prática – 1º Semana



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)

11


Sockets sem Ligação

socketsocketsocketsocket

bindbindbindbind

recvfromrecvfromrecvfromrecvfrom

sendtosendtosendtosendto

socketsocketsocketsocket

bindbindbindbind

sendtosendtosendtosendto

recvfrom recvfrom recvfrom recvfrom

ClienteServidor


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

12


Sockets UDP em Java (Servidor)• import java.net*;


• public class UDPServer{


• 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


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


• import java.net*;


• public class TCPClient{


• // 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)


• import java.net*;


• public class TCPServer{


• 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

14


Aula prática

• SocketClient.java

• SocketServer.java



Integração da Comunicação no Sistema

Operativo

15


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


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

16


Três gerações de sistemas distribuídos

• Sistemas distribuídos iniciais

– Final da década de 70, início da década de 80

– 10-100 nós ligados por uma rede local, ligação limitada à internet

– Poucos serviços oferecidos (partilha de ficheiros, impressoras, email)

• Sistemas à escala da Internet

– Década de 90

– Sistema global de larga escala, composto por redes de redes

– Altamente heterogéneo

– Nós são essencialmente servidores e desktops

• Sistemas contemporâneos

– Inclui nós móveis (laptops, smart phones, etc)

– Inclui nós embebidos em “coisas” (e.g. máquinas de lavar, smart

homes)

– Nós autónomos substituídos por grupos de nós que oferecem serviços

na Cloud12/13 Sistemas Distribuídos 43


Três gerações de sistemas distribuídos


17


Modelos arquitecturais



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)


Por omissão, assumiremos

sistema distribuído de processos

18


Como comunicam estas entidades?



Est

ud

arem

os

ambo

s em

bre

ve

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


19



Exemplo: chamada remota de procedimentos


CLIENTE SERVIDOR

Cliente bloqueado

Bloqueia-se

Chamada ao procedimento remoto:

envio dos parâmetros

Execução do

procedimento

pedido

Retoma a execuçãoRetorno do procedimento remoto:

devolução dos resultados

Sistemas Distribuídos 2009/10



Exemplo: invocação remota de métodos

• As potencialidades da noção de objecto tornaram-na

atractiva para descrever diversos conceitos em Eng.

Informática

– dando origem a uma tendência de evolução que se designa por

OO de Object Oriented

• Diferenças entre a aproximação baseada em objectos e

uma arquitectura cliente-servidor:

– No RPC invocam-se funções, os dados são entidades separadas

– Num sistema de objectos invoca-se uma função num

determinado objecto que, como contém o seu próprio estado,

torna indissociável a invocação da operação dos dados a que

se aplica


20


m4

m5

m6

Interface

Remota

m1

m2

m3

Código

dos

métodos

Dados

Objecto remoto


Exemplo: invocação remota de métodos


• Exemplos de Plataformas– RMI do Java

– DCOM – Distributed Component Object Model - Microsoft

– Common Object Request Broker Architecture (CORBA) - Object Management Group (OMG)


Comunicação indirecta

• Em comunicação directa, em geral:

– Emissor tem de conhecer receptor

– Emissor e receptor têm de existir simultaneamente

• Paradigmas de comunicação indirecta

introduzem terceira entidade para permitir:

– Desacoplamento espacial

• Emissor de mensagem não precisa conhecer receptor(es)

– Desacoplamento temporal

• Emissor e receptor não têm de existir simultaneamente


21


Comunicação indirecta: paradigmas

• Comunicação em grupo

– Suporte a comunicação um-para-muitos

– Emissor envia mensagem a um identificador de grupo

• Não precisa saber quem são os membros do grupo

• Sistemas publicador/subscritor (publish-subscribe)

– Publicadores emitem mensagens (chamadas eventos)

– Subscritores registam-se e expressam interesse em

determinados eventos

– Cada mensagem publicada é disseminada aos subscritores

interessados




• Filas de mensagens

– Troca de mensagens ponto-a-ponto em que há desacoplamento

espacial/temporal

– Emissor coloca mensagem em fila (mantida por um servidor central -

broker), receptor retira mensagem de uma fila

– As mensagens recebidas pelo broker podem ser reformatadas,

combinadas ou modificas por forma a serem entendidas pelo sistema

de destino

– Normalmente não é necessário modificar os sistemas envolvidos. Os

Message Brokers fornecem adaptadores para as aplicações mais

comuns (SAP, Baan, PeopleSoft, etc.).


22



• Partilha de memória distribuída

– Permitem que processos que não partilham

memória física escrevam e leiam estruturas de

dados em memória distribuída

– Sistema mantém cópias locais da memória

partilhada e sincroniza alterações através de troca

de mensagens

• Tudo transparentemente à aplicação

– Variante recente deste paradigma: espaços de

tuplos



Papéis e responsabilidades


23


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:



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


24


Entre-Pares (Peer-to-Peer)



Como mapear objectos e serviços no

modelo físico?


25


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



Serviço Oferecido por Múltiplos Servidores


26


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



Servidores Proxy e Caches


27


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



Código Móvel (Applets)


28


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



Modelos fundamentais


29



• 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




• 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


30


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


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

31


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

2 - Modelos e Arquitecturas -2013 v3.ppt [Modo de...

Documents

Transcript of 2 - Modelos e Arquitecturas -2013 v3.ppt [Modo de...