Modelos e Arquitecturas 2013
Transcrição
Modelos e Arquitecturas 2013
Departamento de Engenharia Informática Sistemas Distribuídos Revisão de redes Modelos e arquitecturas 12/13 Sistemas Distribuídos 1 Departamento de Engenharia Informática 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 Ca Revisão baseada nos Capitulos do livro 2, 3 e 4 12/13 Sistemas Distribuídos 2 Departamento de Engenharia Informática Aplicações Middleware Bibliotecas (DLL) Protocolos Servidores Sistema Operativo Plataformas de Middleware Nova camadas de software Middleware Plataformas Hardware Os Sistemas Distribuídos são suportados por diversas componentes frequentemente designadas por plataformas de Middleware 12/13 Sistemas Distribuídos 3 Departamento de Engenharia Informática A rede que interliga o sistema distribuído Revisão 12/13 Sistemas Distribuídos 4 Departamento de Engenharia Informática Programação da comunicação: modelo porto porto Canal de comunicação modo utilizador lógico rede rede transporte API da comunicação Processo físico Processo modo sistema 12/13 Sistemas Distribuídos 5 Departamento de Engenharia Informática Redes de Dados • Fornecer uma base mínima de compreensão das redes de dados – Arquitectura – Organização – Protocolos Revisão • Identificar os aspectos relevantes das redes de dados na concepção de sistemas distribuídos 12/13 Sistemas Distribuídos 6 Departamento de Engenharia Informática Características habituais das Arquitecturas Físicas •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 12/13 •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 Sistemas Distribuídos 8 Departamento de Engenharia Informática Modelo OSI 12/13 Sistemas Distribuídos 10 Departamento de Engenharia Informática Modelo OSI Do nível físico ao nível transporte Processo Utilizador Rede IP Rede TCP Frame Relay Anel (ring) ATM GPRS Ethernet Malha (mesh) UMTS Bus Processo Utilizador 12/13 Sistemas Distribuídos 11 Departamento de Engenharia Informática OSI - Nível Físico • 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. Anel (ring) • 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 conectores 12/13 Sistemas Distribuídos Malha (mesh) Bus 12 Departamento de Engenharia Informática OSI - Nível Lógico ou Ligação de Dados • 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 12/13 Frame Relay ATM GPRS Ethernet UMTS Sistemas Distribuídos 13 Departamento de Engenharia Informática OSI - Nível Rede Rede IP • 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 12/13 Sistemas Distribuídos 14 Departamento de Engenharia Informática Processo Utilizador Nível Transporte Rede TCP • 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 12/13 Processo Utilizador Sistemas Distribuídos 15 Departamento de Engenharia Informática A Internet como um Relógio de Areia Mail Web Audio Passível de alterações Maior inovação Ethernet 12/13 VoIP Video IM TCP / UDP Web Services Difícil de alterar IP GPRS 802.11 Satélite Sistemas Distribuídos Bluetooth 16 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) Exemplos Problemas? • telnet, rlogin, Winrdpaplicações de terminal remoto • ftp, samba – Transferência de ficheiros • SMTP – Correio electrónico 12/13 • Cada aplicação possui um protocolo próprio • Dificulta a utilização do protocolo por terceiros • Desempenho porque é executado em modo utilizador Sistemas Distribuídos 17 Departamento de Engenharia Informática Interfaces de Comunicação Máquina A aplicação Sockets, TLI OS kernel 12/13 Máquina B Níveis 7a5 Nível 4 Transporte Níveis 3a1 Níveis 7a5 Nível 4 Transporte Níveis 3a1 Sistemas Distribuídos aplicação Sockets, TLI OS kernel 18 Departamento de Engenharia Informática Caracterização do canal de Comunicação Tipos de canais • 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 12/13 Sistemas Distribuídos 19 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 12/13 Sistemas Distribuídos 20 Departamento de Engenharia Informática Aula Prática – 1º Semana 12/13 Sistemas Distribuídos 22 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) Departamento de Engenharia Informática Sockets sem Ligação Servidor Cliente socket socket bind bind sendto recvfrom sendto recvfrom 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[]){ Constrói um socket datagram // args give message contents and server hostname DatagramSocket aSocket = null; (associado a qualquer porto try { disponível) aSocket = new DatagramSocket(); byte [] m = args [0].getBytes(); InetAddress aHost = InetAddress.getByName(args[1]); Conversão do nome Int serverPort = 6789; DNS para endereço IP 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); Cada mensagem aSocket.receive(reply); System.out.println(“Reply:” + new enviada tem que String(reply.getData())); levar junto } catch (SocketException e){System.out.println(“Socket:” + e.getMessage()); identificador do } catch (IOException e){System.out.println(“IO:” + e.getMessage()); processo destino: } finally { if(aSocket ! = null) aSocket.close();} IP e porto } } 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; Constrói um socket datagram try{ (associado ao porto 6789) 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(), Recebe mensagem request.getPort()); aSocket.send(reply); } Extrai da } catch (SocketException e){System.outprintln(“Socket:”+ mensagem o e.getMessage()); IP e porto do } catch (IOException e){System.out.println(“IO:” + e.getMessage()); processo } finally {if(aSocket ! = null) aSocket.close();} origem para } responder } Departamento de Engenharia Informática Sockets com Ligação Servidor Cliente socket Servidor bind Socket Escuta listen socket accept connect read write write read Socket Ligação Cliente bytes bytes Socket Cliente Departamento de Engenharia Informática Sockets Stream em Java (Cliente) • • • • • • • • • • WriteUTF / • readUTF – • para • Universal • transfer • • format / para • as cadeias de • caracteres • • • import java.net*; import java.io*; public class TCPClient{ public static void main(String args[]){ • classe Socket – suporta o socket // args: message and destin. hostname Socket s = null; cliente. Argumentos: nome DNS try{ do servidor e o porto. int server Port = 7896; • Construtor não só cria o socket s = new Socket (args[1], serverPort); DataInputStream = new como efectua a ligação TCP DataInputStream(s.getInputStream()); DataOutputStream out = newDataOutputStream (s.getOutputStream()); out.writeUTF(args[0]); String data = in.readUTF(); Métodos getInputStream / System.out.prtintln(“Received: ” + data); getOutputStream – permitem }catch (UnknownHostException e){ aos dois streams System.out.println(“Sock:”aceder + e.getMessage()); }catch (EOFException definidos pelo socket 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} } Departamento de Engenharia Informática Sockets Stream em Java (Servidor) • • • • • • • • • import java.net*; import java.io*; Cria socket servidor que fica à public class TCPServer{ escuta no porto “serverPort” public static void main(String args[]){ try{ Bloqueia até cliente int server Port = 7896; estabelecer ligação. 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());} Cria novo socket servidor com quem é } estabelecida ligação com o cliente e } onde os dados são recebidos Departamento de Engenharia Informática Aula prática • SocketClient.java • SocketServer.java 12/13 Sistemas Distribuídos 32 Departamento de Engenharia Informática Integração da Comunicação no Sistema Operativo 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 Departamento de Engenharia Informática Winsock Implementation Application Mswsock.dll SPI Msafd.dll Wshtcpip.dll Service Providers Ntdll.dll NtReadFile, NtWriteFile, NtCreateFile, NTDeviceloControlFile User mode Kernel mode \Device\AFD TDI IRPs Protocol drivers IPX/SPX AFD FSD TDI NetBEUI TCP/IP Departamento de Engenharia Informática 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 Cloud 12/13 Sistemas Distribuídos 43 Departamento de Engenharia Informática Três gerações de sistemas distribuídos 12/13 Sistemas Distribuídos 44 Departamento de Engenharia Informática Modelos arquitecturais 12/13 Sistemas Distribuídos 45 Departamento de Engenharia Informática Quem são as entidades que comunicam através da rede num sistema distribuído? Por omissão, assumiremos sistema distribuído de processos • 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) 12/13 Sistemas Distribuídos 46 Departamento de Engenharia Informática Como comunicam estas entidades? 12/13 Sistemas Distribuídos 47 Departamento de Engenharia Informática Comunicação directa • Interface de comunicação entre-processos • Invocação remota – Protocolos de pedido-resposta • Exemplo: HTTP Estudaremos ambos em breve – 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 12/13 Sistemas Distribuídos 48 Departamento de Engenharia Informática Comunicação directa Exemplo: chamada remota de procedimentos CLIENTE SERVIDOR Chamada ao procedimento remoto: envio dos parâmetros Bloqueia-se Execução do procedimento pedido Cliente bloqueado Retoma a execução Retorno do procedimento remoto: devolução dos resultados Sistemas Distribuídos 2009/10 12/13 Sistemas Distribuídos 49 Departamento de Engenharia Informática Comunicação directa 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 12/13 Sistemas Distribuídos 50 Departamento de Engenharia Informática Comunicação directa Exemplo: invocação remota de métodos Objecto remoto Interface Remota Dados m1 m2 m3 • Código dos métodos m4 m5 m6 Exemplos de Plataformas – RMI do Java – DCOM – Distributed Component Object Model - Microsoft – Common Object Request Broker Architecture (CORBA) - Object Management Group (OMG) 12/13 Sistemas Distribuídos 51 Departamento de Engenharia Informática 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 12/13 Sistemas Distribuídos 52 Departamento de Engenharia Informática 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 12/13 Sistemas Distribuídos 53 Departamento de Engenharia Informática Comunicação indirecta: paradigmas • 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.). 12/13 Sistemas Distribuídos 54 Departamento de Engenharia Informática Comunicação indirecta: paradigmas • 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 12/13 Sistemas Distribuídos 55 Departamento de Engenharia Informática Papéis e responsabilidades 12/13 Sistemas Distribuídos 57 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 Client invocation Server invocation result result Server Client Key: Process: 12/13 Computer: Sistemas Distribuídos 58 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 Sharable • Mais ampla distribuição objects de carga (computação e rede) Peer 2 Peer 1 Application Application Peer 3 Application – Maior escalabilidade – Sistema expande-se acrescentando mais pares Peer 4 Application Peers 5 .... N • Coordenação mais complicada que clienteservidor 12/13 Sistemas Distribuídos 59 Departamento de Engenharia Informática Entre-Pares (Peer-to-Peer) 12/13 Sistemas Distribuídos 60 Departamento de Engenharia Informática Como mapear objectos e serviços no modelo físico? 12/13 Sistemas Distribuídos 61 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 12/13 Service Server Client Server Client Server Sistemas Distribuídos 62 Departamento de Engenharia Informática Serviço Oferecido por Múltiplos Servidores 12/13 Sistemas Distribuídos 63 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 Web server Client Proxy server Web server Client 12/13 Sistemas Distribuídos 64 Departamento de Engenharia Informática Servidores Proxy e Caches 12/13 Sistemas Distribuídos 65 Departamento de Engenharia Informática Código Móvel (Applets) a) client request results in the downloading of applet code Client Applet code Web server b) client interacts with the applet Client Applet Web server • 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 12/13 Sistemas Distribuídos 66 Departamento de Engenharia Informática Código Móvel (Applets) 12/13 Sistemas Distribuídos 67 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 12/13 Sistemas Distribuídos 68 Departamento de Engenharia Informática Modelos fundamentais 12/13 Sistemas Distribuídos 69 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 12/13 Sistemas Distribuídos 70 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 12/13 Sistemas Distribuídos 71 Departamento de Engenharia Informática Modelo de Interacção Mais à frente no semestre, analisaremos modelos de interacção em maior detalhe • 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 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 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