IA844 Sistemas Distribuídos Redes e Sistemas Abertos...

03/09/2008

1

IA844Redes e Sistemas Abertos de

Comunicação

Prof. Eleri CardozoDCA/FEEC/Unicamp

[email protected]://www.dca.fee.unicamp.br/~eleri

Dra. Eliane Gomes GuimarãesCTI Renato Archer

[email protected]

1IA844 - Prof. Eleri Cardozo IA844 - Prof. Eleri Cardozo 2

Sistemas Distribuídos

Um sistema distribuído é um sistema computacional com as seguintes propriedades:

1. Distribuição: um subconjunto de seus componentes são controlados por entidades independentes e dispersas (processos, máquinas virtuais, etc.).

2. Concorrência: um subconjunto de seus componentes executam concorrentemente (paralelismo real ou pseudo-paralelismo).

3. Falhas parciais: qualquer componente do sistema pode falhar independentemente dos demais.

4. Assincronismo: as atividades do sistema não são regidas por um relógio global (por exemplo, pode ser impossível estabelecer causa-efeito ou determinar precisamente o estado do sistema).

IA844 - Prof. Eleri Cardozo 3

Sistemas Abertos

Sistemas abertos são sistemas implementados segundo padrões abertos.

Padrão aberto: documento estabelecido por consenso e publicado por organismo de padronização acreditado para uso comum e repetitivo. Exemplo: Protocolos TCP/IP (IETF), RM-ODP (ISO), UML (OMG).

Padrão de-facto: padrões aceitos por razões de disponibilidade, custo, convêniência, etc. Exemplo: Windows, Linux, Java, MATLAB.

OBS: 1. A motivação para uso de padrões aberto é a independência de fornecedores.

2. Um sistema desenvolvido segundo padrões abertos não necessariamente é um sistema gratuito ou de código aberto.


Sistemas Abertos: Classificação

Podemos classificar sistemas abertos em quatro categorias:

1. Modelos de referência: descrevem os componentes do sistema, suas funções, relações e formas de interação. Exemplo: Modelos OSI e ODP.

2. Arquiteturas de referência: igual aos modelos de referência, mas com especificação mais precisa das interfaces e pontos de referência entre os componentes do sistema. Exemplo: Arquiteturas SOA e OMA.

3. Arquiteturas abertas: igual às arquiteturas de referência, mas com especificação precisa dos protocolos de interação entre os componentes do sistema. Exemplo: Arquiteturas CORBA e TCP/IP.

4. Implementações de referência: provêem código aberto (gratuito ou não) para os componentes fundamentais da arquitetura. Exemplo: Linux kernel e Projetos da Apache.

O grau de interoperabilidade é menor para os modelos de referência e maior para as implementações de referência.

03/09/2008

2


Exemplo: Arquitetura CORBA

Object Request Broker (ORB)

Objetos deAplicação

CORBAServices

CORBAFacilities

Arquitetura OMA

IDL (Interface Description Language)

IIOP (Internet Inter-ORB Protocol)

OMA + IDL + IIOP = CORBA


Desenvolvimento de Sistemas Distribuídos

Infra-estrutura necessária:� Hardware: rede de computadores, multiprocessador, processador multitarefa� Software: ORBs, middlewares, contêineres, ...

A infra-estrutura de hardware é responsável por:� Suportar a distribuição do processamento;� Suportar comunicação entre os elementos do sistema.

A infra-estrutura de software é responsavel por:� Prover transparência (esconder a distribuição) aos componentes do sistema;� Atender a um subconjunto de requisitos não-funcionais do sistema.



Um sistema distribuído é especificado em diferentes níveis de abstração e/ou visões (viewpoints).

A parte mais importante da especificação é sua arquitetura.

Uma arquitetura de software define os elementos (objetos, módulos, componentes, etc.) que compõem o sistema, a estruturação destes elementos (camadas, tiers, clusters, etc.), as relações entre os elementos (cliente/servidor, produtor/consumidor, etc.), e as propriedades visíveis externamente destes elementos e relações (pontos de interação).



Atualmente, a tendência é se concentrar mais na arquitetetura e menos nas tecnologias de implementação:� favorece o reuso de arquiteturas (em oposição ao reuso de código);� alterar a arquitetura em fase adiantada de desenvolvimento é extremamente custoso;� ferramentas de desenvolvimento de software possuem capacidade crescente de geração de código.

Adotam esta estratégia:� ODP: Visão de tecnologia; � MDA (Model-driven Architecture): PIM (Platform Independent Model).

03/09/2008

3


Redes de ComputadoresRede de Telefonia

Redes Locais

CATV

Redes de Acesso(Última Milha)

(Cable Modem,ADSL, Fibra)

Troncos(Fibra ótica)SONET/SDH

Redes ATM

Redes TCP/IP

Ethernet Wireless

VoIP IPTV

Fixa Móvel

2G, 3G

WWW

WiFi/WiMax

Sensores

Veicular

Corporal

...

Chão deFábrica

Tecnologias(camadas 1,2)

Aplicações(camadas 5,6,7)

Fibra Ótica(DWDM)

Comunicação(camadas 3,4)


Redes de Computadores

Modelo OSI (ISO): um modelo de referência para redes de computadores.

Protocolos ISO para o modelo OSI: conjunto de protocolos para os elementos (camadas) do modelo OSI.

Arquitetura TCP/IP (IETF): arquitetura de rede não aderente ao modelo OSI.

Outras arquiteturas de rede: NetWare (Novell), IN (Rede Inteligente) (ITU-T), SNA (IBM).


Modelo OSI

Rede

Física

Enlace

Transporte

Sessão

Apresentação

Aplicação

Transmissão de bits no meio físico

Transferência de quadros entre nós próximos

Transferêrncia de pacotes (store-and-forward)

Transferência de segmentos fim-a-fim

Manutenção de estado da comunicação fim-a-fim

Formatação canônica de dados

Infra-estrutura para o desenvolvimento de aplicações


Modelo OSI: Exemplo

Rede

Física

Enlace

Transporte

Sessão

Apresentação

Aplicação

Par trançado (100BaseT)

Ethernet (IEEE 802.3)

Internet Protocol (IP), Address Resolution Protocol (ARP)

Transfer Control Protocol (TCP)

Secure Socket Layer (SSL)

Hypertext Markup Language (HTML)

Hypertext Transfer Protocol (HTTP, HTTPS)

Navegador Web

03/09/2008

4


Modelo OSI: Visão Geral

4-7

1-3 1-3 1-3

1-3

4-7

1-3

1-3

roteamento

comunicaçãoem broadcast

comunicação fim-a-fim

subrede decomunicação

OBS: Esta visão “OSI” não é mais atual. Exemplo:� meio físico dedicado (switching);� roteamento baseado em restrições;� L2-VPNs (Layer 2 Virtual Private Networks).

comunicaçãoponto-a-ponto


Arquitetura TCP/IP

Interface de Rede

Interconexão de Redes

Transporte

Aplicação

Rede

Física

Enlace

Transporte

Sessão

Apresentação

Aplicação

OBS: Na arquitetura TCP/IP a camada de aplicação é responsável pela representação canônica de dados (apresentação) e por manter o estado da comunicação (sessão).


Protocolos TCP/IPA camada interface de rede não prescreve protocolos específicos.

A camada de rede define os seguintes protocolos:� IP (Internet Protocol): define o formato de um pacote de rede (datagrama);� ARP (Address Resolution Protocol): mapeia endereços de rede em endereços de interface de rede (enlace);� ICMP (Internet Control Message Protocol): define mensagens de controle (p.ex., echo request) e erros (e.g., host unreachable).

A camada de transporte define os seguintes protocolos:� TCP (Transfer Control Protocol): transporte de cadeia de bytes com garantia de entrega fim-a-fim;� UDP (User Datagram Protocol): transporte de mensagens sem garantia de entrega fim-a-fim.

A camada de aplicação define vários protocolos tais como HTTP, SMTP (Simple Mail Transfer Protocol) e SSH (Secure Shell).


Protocolos TCP/IP

Além dos protocolos básicos, a Arquitetura TCP/IP especifica umgrande número de protocolos de rede e aplicação, por exemplo:

Camada de rede:� IPSec (IP Secure): confidencialidade e integridade de pacote IP;� OSPF (Open Shortest Path First): roteamento de pacotes IP;� RSVP (Resource Reservation Protocol): reserva de recursos para comunicação;� DiffServ (Serviços Diferenciados): priorização de pacotes;� DHCP (Dynamic Host Configuration Protocol): atribuição de endereços de rede.

Camada de Aplicação:� SNMP (Simple Network Management Protocol): gerência de rede;� DNS (Domain Name System): mapeamento nome hierárquico-endereço de rede;� NAT (Network Address Translation): mapeamento endereçamento privado-público.

03/09/2008

5


Endereçamento TCP/IP

Endereço físico(distingue a conexão ao meio físico)

Física

Endereço de enlace(distingue a interface de rede no enlace)

Endereço de rede(distingue globalmente a interface)

Enlace

Rede

TransporteEndereço de transporte(distingue um ponto de acesso à rede utilizado por aplicação)

AplicaçãoEndereço de aplicação(distingue um serviço ou aplicação)


Mapeamento de Endereços TCP/IP

Física

Enlace

Rede

Transporte

Aplicação

hardwired

00:11:43:CF:06:53

ARP (Address Resolution Protocol)

143.106.50.145

8080

prainha.dca.fee.unicamp.br

DNS (Domain Name System)

http://prainha.dca.fee.unicamp.br:8080/

RJ-45


Endereços IP

Camada de rede: utiliza endereçamento de 32 bits hierarquizados em dois níveis (subrede - host)� Classe A: 7 bits para subrede e 24 para host;� Classe B: 14 bits para subrede e 16 para host;� Classe C: 21 bits para subrede e 8 para host.

Notação decimal: valor decimal de 8 bits separados por pontoExemplo: 143.106.8.30

Notação classless: notação decimal / tamanho do prefixo (agrega 2N endereços consecutivos)Exemplos: 143.106.8/24 (rede com 256 hosts), 143.106.8/26 (rede com 1024 hosts), 143.106.8.30/32 (host específico)


Por que TCP/IP Prevaleceu ?

Não especificar protocolos de rede e enlace permitiu evoluir as tecnologias de rede e preservar as aplicações (a custa do protocolo ARP).

Camada de rede simples com serviço de melhor-esforço (protocolo IP) barateia os roteadores.

Deixa para os computadores dos usuários o ônus da comunicação confiável e o controle de congestionamento (protocolo TCP) -- escalabilidade.

Fácil de configurar (protocolo DHCP).

Compartilhamento de endereços públicos (NAT).

Portabilidade de aplicações (sockets).

Killing application (WWW).

03/09/2008

6


Requisitos de Rede

Requisitos Funcionais:

Transporte de bytes entre componentes do sistema distribuído.

Requisitos Não Funcionais:� Confiabilidade (taxa de perdas, probabilidade de falha, ...);� Segurança (privacidade, autenticidade, ...);� Qualidade de serviço (atraso, jitter, ...);� Classes de serviço (priorização de tráfego)� Mobilidade (de terminal, de sessão, ...).

Os requisitos funcionais são atendidos pelas camadas 1-7. Os requisitos não funcionais podem necessitar de infra-estrutura adicional (Gerência baseada em políticas, QoS brokers, etc.).


Requisitos de Rede

Que requisitos de rede TCP/IP é capaz de atender ?

a. Segurança: atende razoavelmente bem com mecanismo de chaves criptográficas (ex: HTTPS);b. QoS (atraso, jitter): não atende (Internet atual);c. CoS: atende em redes privadas com equipamentos adequados (ex: priorização de tráfego VoIP);d. Mobilidade: não tende.

Cenário hoje:

a. sobre-provisionamento de recursos para QoS/CoS;b. mobilidade apenas na camada 2 (ex: WiFi) ou via redes sobrepostas (ex: IP em redes de telefonia celular).


Qualidade de Serviço

Visão OSIQoS nas camadas 1,2,3 garantidos por controle de admissão;QoS nas camadas superiores negociados no estabelecimento de conexões.

Visão TCP/IP (original)Campo TOS (Type of Service) no datagrama IP utilizado para definir o tipo de serviço conferido ao datagrama pelos roteadores.

Visão TCP/IP (Arq. de Serviços Integrados - IntServ)Utiliza-se um protocolo para sinalizar reserva de recursos na camada 3 (RSVP).

Visão TCP/IP (Arq. de Serviços Diferenciados - DiffS erv)Redefine-se o campo TOS para identicar classes de serviço.


Conexões

Uma conexão é uma negociação entre duas camadas adjacentes (por meio de seus respectivos protocolos) visando dotar a comunicação de certos atributos relavantes para a camada. Por exemplo, para a camada de rede atributos de taxa de transferência e atraso são importantes; para a camada de transporte ausência de perdas é importante.

Conexões garantem a utilização dos recursos de forma planejada (por exemplo, evitando congestionamento nos roteadores).

Entretanto, a complexidade dos protocolos orientados a conexão é muito maior em relação àqueles que operam sem conexão.

03/09/2008

7


Campo TOS

De acordo com o valor do campo TOS, o roteador confere um tratamento adequado ao pacote:� máxima vazão;� máxima confiabilidade;� mínimo atraso;� máxima segurança.� mínimo custo monetário.

Problema: os roteadores primitivos não tinham como honrar o campo TOS.

Resultado: serviço de melhor esforço independente do campo TOS.


Arquitetura IntServ

Solução orientada a fluxo.

R RRfluxo� Estabelece reserva de recursos para um fluxo individual.� Define um modelo de reoteador capaz de diferenciar fluxos. � Define um protocolo para reserva de recursos por fluxo.

A B

estado


Roteadores IntServ

Agente deRoteamento(e.g., OSPF)

Base de Dados(Tabela) deRoteamento

Agente deReserva

(e.g., RSVP)

Agente deGerência

(e.g., SNMP)

Controle deAdmissão

Controlede Tráfego

Classificadorde Pacotes

Escalonadorde Pacotes

Interfacede Saída

Interfacede

Entrada

Roteadorde Pacotes

Filas


Protocolos IntServA Arquitetura IntServ define o protocolo RSVP (Resource Reservation Protocol). RSVP é um protocolo:

- soft state;- extensível (cabeçalho simples + objetos);- complexo (combinação e compartilhamento de reservas);- exige tráfego modelado por meio de token bucket.

A B

R RR

Path (fluxo, Tspec)

Resv

A mensagen Path instala (e “refresca”) o estado e Resv confirma o estado.

03/09/2008

8


IntServ: Legado

A arquitetura IntServ foi uma proposta muito radical:� estabele conexão no nível de rede !!!� exige roteadores complexos (e portanto caros);� exige sinalização no host (externa à rede);� não é solução escalável (estado e controle por fluxo).

Pelas razões acima, IntServ nunca foi utilizada pelos provedores de rede. Entretanto ...� o modelo de roteador IntServ prevalece;� o protocolo RSVP é empregado em outas arquiteturas de rede (ex: MPLS);� a idéia é viável se houver agregação de fluxo (como no MPLS).


Arquitetura DiffServ

Solução orientada a diferenciação de serviços:� define-se N classes de serviço;� para cada classe, define-se um comportamento homogêneo para pacotes pertencentes à classe (per hop behavior - PHB).

Classes de serviço são especificadas separadamente. Cada classe é identificada por um código no campo TOS (DiffServ Code Point - DSCP) e pode possuir mais de uma subclasse. Cada subclasse pode possuir mais de uma “prioridade de descarte”. Atualmente existem 3 classes:� EF (Expedited Forward) - similar a uma “linha privada virtual” - não define subclasses;� AF (Assured Forward) - “melhor que melhor esforço” - define 4 subclasses com 3 prioridades de descarte cada;� BE (Best Effort) - serviço padrão - não define subclasses.


Roteadores DiffServ

Medidorde Tráfego

Classifi-cador dePacotes

Escalo-nador dePacotes

Interfacede

Saída

Interfacede

Entrada

Roteadorde

Pacotes

Filas

AF1

BE

EF

Condicio-nador dePacotes

Marcadorde

Pacotes ...

Agente deRoteamento(e.g., OSPF)

Base de Dados(Tabela) deRoteamento

Agente deGerência

(e.g., SNMP)

SLAs (Service Level Agreements)


DiffServ Hoje� Utilizada em redes privadas e entre provedores de rede; � Marcação pelo host usualmente ignorada pela rede;� Apesar de escalar melhor que IntServ, o tratamento de SLAs pode ainda comprometer a escalabilidade;� Cenário provável:

Provedor de Rede

Provedorde ConteúdoRede de

Acesso

SLA

DiffServAlocaçãode Banda

Usuário

03/09/2008

9

Redes IP Móveis


Mobilidade na camada de rede: o terminal muda de subrede e preserva as conexões de transporte. O processo de mudança de subrede é denominado “handover”.

• Macro-mobilidade: handover entre domínios• Micro-mobilidade: handover interior ao domínio

Protocolos:

• Baseados em tunelamento entre as redes home e visitada• Baseados em roteamento móvel

Handover


Handover de camada 2 (trocas de ponto de acesso): em redes WiFi é realizado automaticamente pelo nó móvel em função da relação sinal-ruido medida entre as redes já configuradas.

Handover de camada 3 (troca de subrede): realizado quando algum evento (trigger) no nó móvel indicar que ocorreu uma mudança de subrede:• o nó móvel realizou handover de camada 2 para rede com ESSID diferente;• mensagens de Router Advertisement (IPv6) indicam que o prefixo da subrede mudou;• o nó movel perdeu sua conectividade com a rede atual.

Protocolos Baseados em Tunelamento


Utilizam endereço “home” e endereço(s) “foreign”:

HoA: Home address – endereço permanente e roteávelCoA: Care-of Address – endereço transiente e roteável.

Protocolos:

• Mobile IPv4 (MIPv4) – suportada macro-mobilidade• Mobile IPv6 (MIPv6) – suporta macro-mobilidade• Hierarchical MIPv6 (HMIPv6) – adiciona ao MIPv6 suporte a micro-mobilidade• Proxy MIPv6 (PMIPv6) – idem ao HMIPv6

MIPv6


Home Agent(“defende” HoA do nó móvel)

Home Network

Foreign Network

Correspondent Node

Tunel IP/IP

Nó Móvel

HoaCoa

Tunel IP/IP (opcional)

03/09/2008

10

MIPv6 - Sinalização


HA

HomeNetwork

ForeignNetwork

CorrespondentNode

MN

BindingCache

BindingUpdate(HoA, CoA)

BindingACK Care-of Test

Init (CoA)

HomeTestInit (HoA)

Care-of Test (CKey)

HomeTest (HKey)

BindingUpdate(HoA, CoAbmKey)

BindingACK

Hkey é gerada a partir de HoACkey é gerada a partir de CoAbmKey é gerada a partir de Hkey e CKey

MIPv6 - Problemas


•Triangularização – toda a comunicação passa pelo HA (se o nó correspondente não suporta MIPv6)

• Requer rede IPv6 e protocolo adicional no nó móvel

• Handover lento (autoconfiguração + DAD)

• Protocolo complexo para dispositivos de baixo poder computacional

• Gera muito tráfego de sinalização (Bindings update, Return Routeability)

• O no móvel precisa ter o papel de servidor?

HMIPv6


• Minimiza o tráfego de sinalização quando ocorre handovers dentro do domínio

• Introduz um novo elemento – MAP (Mobile Anchor Point)

• Novo endereço – RCoA (Regional CoA), LCoA (Local CoA), HoA.

• Altera sinalização do MIPv6

• HA e CN não são afetados pelo HMIPv6

HMIPv6

IA844 - Prof. Eleri Cardozo

40

HA

Home Network

ForeignNetwork

Correspondent Node

Tunel IP/IPDestino: RCoA

MN

Tunel IP/IP (opcional)

Tunel IP/IPDestino: LCoA

MAP

Handover

03/09/2008

11

HMIPv6: Sinalização

IA844 - Prof. Eleri Cardozo

41

HA

Home Network

ForeignNetwork

Correspondent Node

BU (HoA, RCoA)

MN

Local BU (RCoA, LCoA1)

MAP

Local BU (RCoA, LCoA2)

RA (MAP)

BindingCache

HMIPv6: Problemas


• Nó móvel deve escolher qual MAP é “mais próximo”

• Roteadores devem propagar MAPs nas mensagens de RA (quais?)

• MAPs devem realizar DAD para os RCoAs registrados

• MAPs devem interceptar pacotes destinados a RCoA (portanto, devem ser roteadores ou nós que defendem os RCoAs)

PMIPv6: Proxy MIPv6


• Proposta do NETLMM (IETF).

• Propõe que todo o overhead da mobilidade recaia sobre a rede (e não sobre o nó móvel).

• Nenhum protocolo adicional é necessário para o nó móvel.

• Evita que túneis passem por enlaces aéreos.

• Toda a sinalização de mobilidade é restrita à rede de transporte.

• Elimina a necessidade de HoA/CoA (usa um endereço fixo).

• Não requer DAD a cada handover.

PMIPv6


MAG (MobilityAccess Gateway)

MobileNetwork

Correspondent Node

BindingCache

MN

LMA (Local Mobility Anchor)

MAG

HoA HoA

03/09/2008

12

PMIPv6: Sinalização


MAGMobileNetwork

MN

LMA

MAG

HoA-X HoA-X

AAA Server(e.g., Radius)

AAA query(e.g., WPA2) PBU (MNid)

MNid ?

Prefixo YPrefixo X

RA RA emulando X

PMIPv6: Problemas


• Cache do nó móvel deve ser zerada após handover.

• IPv6 requer DAD após autoconfiguração.

• Servidor AAA consultado a cada handover.

• Requer trigger de camada 2 (portanto, a detecção de movimento é dependente da tecnologia da rede sem fio).


Arquiteturas deSistemas Distribuídos


Arquiteturas de SDs

O termo “arquitetura” refere-se a arquitetura de uma aplicação específica (exemplo: e-Banking). O termo “estilo arquitetural” ou “padrão arquitetural” refere-se a um esboço de arquitetura a partir do qual arquiteturas de aplicações podem ser projetadas (exemplo: estilo cliente/servidor).

Arquiteturas que seguem o mesmo estilo arquitetural compartilham propriedades estrututurais semelhantes.

A partir daqui, os termos “arquitetura” e “estilo arquitetural” serão utilizados como sinônimos.

03/09/2008

13


Arquiteturas de SDs

Arquiteturas usualmente estabelecem:

1. Os elementos que compõem a arquitetura;Exemplo: Uma arquitetura de agentes possui os elementos agência e agentes.

2. A estruturação dos elementos da arquitetura;Exemplo: Agentes são elementos contidos em agências (relaçãocontêiner/contido).

3. As relações entre os elementos da arquitetura;Exemplo: Uma agência controla a execução de agentes.

4. Os pontos de interação da arquitetura.Exemplo: Agências interagem entre sí segundo um protocolo de gerência deagentes. Agentes oferecem interfaces de callback para controle por parte daagência. Agências oferecem interfaces para os agentes obterem informaçõessobre o seu ambiente de execução.


Arquiteturas de SDsExemplo de modelagem de arquiteturas


Padrões Arquiteturais� Cliente/Servidor;� n-Tier;� Dirigidas a Eventos e a Mensagens;� Peer-to-Peer (P2P);� Grades Computacionais;� Orientadas a Serviço;� Multi-agentes.


Arquitetura Cliente/Servidor

O sistema é decomposto em elementos clientes e servidores. Servidores provêem serviços por meio de uma ou mais interfaces. Clientes utilizam serviços invocando operações nestas interfaces.

Clientes dependem de servidores para desempenhar suas funções.

A relação entre clientes e servidores é a de provedor/consumidor de serviços. Esta relação é estabelecida apenas durante a execução de serviços.

Um ponto de interação entre clientes e servidores deve explicitar protocolos para descrição de interfaces de serviços e para invocação de serviços.

03/09/2008

14


Protocolos de Interação Cliente/Servidor

RPC (Remote Procedure Call) - O servidor suporta um conjunto de subrotinas que podem ser invocadas dinamicamente.� a passagem de parâmetros e retorno é sempre por valor;� necessita de infra-estrutura para invocação remota.

Infra-estrutura mínima:

bibliotecaRPC

bibliotecaRPC

P1 P2 P3

invocação localcallRPC

protocoloRPC

serializa parâmetrosde-serializa retorno

de-serializa parâmetrosserializa retorno

Cliente

Servidor


Compiladores RPC

Stub

bibliotecaRPC

P2 P3P1

bibliotecaRPC

P1 P2 P3

invocação local

Servidor

Skeleton

protocolo RPC

associação (binding)

Cliente

P1, P2, P3Descrição de interfaces

CompiladorRPC


RPC: Registro de ServidoresServidores devem registrar seus procedimentos para que clientes os encontrem. Registros podem ser locais, centralizados ou distribuídos.

C

Nó

R

S

Nó

R

S

Nó

R

S

Nó

C

Nó

S

Nó

R

S

Nó

S

Nó

C

Nó

S

Nó

S

Nó

S

Nó

R

DistribuídoLocal

Centralizado


RPC: Registro de Servidores

RegistroRegistro:� portmapper� serviço de nomes� negociador (trader)

ServidorCliente

Stub Skeleton

1. registra2. busca

3. invoca

03/09/2008

15


RPC: Registro de Servidores

Portmapper : mapeia procedimentos (programa, versão, procedimento) em um port de servidor local. Exemplo (0x12345678, 1, 2) -> 111

Serviço de nomes : mapeia nomes hierárquico em endereços de servidores. Exemplo: /Servidores/TimeServers/T1/getTime -> (143.106.50.145, 111)

Negociador (Trader) : mapeia nomes hierárquicos e atributos em endereços de servidores locais. Exemplo:/Servidores/TimeServers/T1/getTime {Precision = 99.990} ->(143.106.50.145, 111)

Ao buscar um servidor, o cliente define um critério de busca. Exemplo:/Servidores/TimeServers/*/getTime {Precision > 99.0}


RPC: Protocolos

SUN RPC: Utilizada em serviços como NFS e NIS. Possui linguagem de descrição de procedimentos (RPC Language) e compilador (rpcgen). Opera com registro local (portmapper). Stubs possuem assinaturas diferentes dos procedimentos.

/* RPC Language */program DATE_PROG {version DATE_VERS {long BIN_DATE(void) = 1; /* numero do procedimento */string STR_DATE(long) = 2;} = 1; /* versao */} = 0x12345678; /* numero do programa */

......

/* codigo do cliente */CLIENT cl = clnt_create(server, DATE_PROG, DATE_VERS, “udp”); /* stub */long ldate = bin_date_1(NULL, cl);


RPC: Protocolos

DCE RPC: Utilizada inicialmente no DCE (Distributed Computing Environment), serviu de base para o Microsoft DCOM/COM+. Possui invocação segura e compilador. Stubs possuem assinaturas diferentes dos procedimentos. Hoje disponível em código aberto.

/* DCE IDL */[uuid(70ff8220-6e1a-11cc-89ee-080002b2a1bca)]interface date {long bin_date();[string, prt] str_date ([in] long date);}

........

/* codigo do cliente */rpc_binding_handle_t binding_h; /* stub */unsigned32 dce_status;import_interface(“date”, date_v1.0_c_ifspec, &binding_h, &dce_status);long ldate = time(NULL);char* date = str_date(binding_h, ldate, &dca_status);


Objetos Distribuídos

Comumente arquiteturas cliente/servidor são realizadas com objetos distribuídos. Um objeto distribuído:� possui uma referência que extrapola o seu espaço de endereçamento;� possui uma ou mais interfaces descritas segundo uma linguagem de descrição de interfaces;� é ancorado por uma infra-estrutura que suporta invocação remota dos métodos definidos em sua(s) interface(s).

A infra-estrutura de suporte a objetos distribuídos provê minimamente:� stubs e skeletons gerados para uma dada interface;� mecanismo de ligação stub-skeleton (binding).

Adicionalmente a infra-estrutura pode prover:� mecanismo de controle de execução e persistência de objetos distribuídos;� serviços adicionais (segurança, transação, etc.).

03/09/2008

16


Objetos Distribuídos: CORBA

Stub

bibliotecaORB

P2 P3P1

bibliotecaORB

O1 O2 O3

invocaçãolocal

Servidor

Skeleton

protocolo IIOP

associação (binding)

Cliente

I1, I2, I3Descrição de interfaces: CORBA IDL

CompiladorIDL

POA

controle

Objetos serventes


Objetos Distribuídos: CORBA

// CORBA IDLinterface date {long bin_date();string str_date(in long ldate);}

......

// clienteorg.omg.CORBA.Object obj = nserver.resolve_str(“TimeServer”);

date dt = dateHelper.narrow(obj); /* stub */long ldate = dt.bin_date();String str = str_date(ldate);


Arquitetura n-Tier

Variante da arquitetura Cliente/Servidor onde os elementos da aplicação distribuída são estruturados em camadas verticais (tiers). Comumente são empregadas 3 camadas (Arquitetura 3-Tier):

- Apresentação : contém os elementos responsáveis pela interação com o usuário.

- Lógica da Aplicação (de negócio): contém os elementos responsáveis pela lógica da aplicação (processamento da informação).

- Dados (Back-End) - contém os elementos responsáveis pela persistência e consistência dos dados.

Elementos de uma camada interagem apenas com elementos de camadas adjacentes.

Pontos de interação entre camadas devem explicitar protocolos para descrição de interfaces de serviços e para invocação de serviços disponíveis em cada camada.


Exemplo de Arquitetura 3-Tier

Apresentação

EJBContainer

(EnterpriseJava Beans)

WebContainer

(JSP/Servlet)

Base deDados

Relacional

Lógica daAplicação

Dados(Back-End)

HTTPRMI

JDBCJava BeansHibernate

03/09/2008

17


Arquitetura Dirigida a Eventos e Mensagens

O sistema é decomposto em elementos produtores e consumidores de eventos (mensagens).

Produtores e consumidores são desacoplados por meio de um canal de difusão de eventos (mensagens).

Produtores e consumidores de eventos (mensagens) dependem do canal de difusão para desempenhar suas funções.

Um ponto de interação entre produtores, consumidores e canal de difusão deve explicitar protocolos e interfaces para subscrição, “de-subscrição”, publicação e consumo de eventos (mensagens).



ProxyConsumidor

ProxyProdutor

Admin

Persistência

Produtor

Produtor

push

subscribeunsubscribe

pull

Consumidor(push)

Consumidor(pull)

push

Canal deDifusão



Exemplo de infra-estruturas de eventos/mensagens:� Serviço de Notificação e de Mensagens CORBA;� Java Message Systems (JMS);� ActiveMQ (Apache);� WebSphere MQ (IBM).


Arquitetura Peer-to-Peer (P2P)

O sistema é composto de elementos que desempenham funções semelhantes (elementos pares).

Não há uma estruturação definida para os elementos pares, apesar de prevalecer uma estruturação em grafos não orientados.

Não há relação de dependência ou hierarquia entre os elementos pares.

Um ponto de interação entre pares deve ser definido para que estes possam cooperar (tipicamente por meio de troca de mensagens).

Arquiteturas P2P são comumente empregadas em redes de compartilhamento de informação (Gnutella, Napster, etc.) e de processamento cooperativo (SETI@Home, Entropia, etc).

03/09/2008

18


Arquitetura P2P

Rede de suporte ( underlay, e.g., Internet)

Rede suportada ( overlay, e.g., Gnutella)

peer

Topologia, protocolos de interação e funcionalidade dos nós diferem entre as duas redes.


Exemplo de Arq. P2P: Gnutella

Gnutella é uma arquitetura de propósito geral para compartilhamento de informação (tipicamente arquivos). Gnutella define um protocolo de interação entre os nós que suporta:� descoberta de pares (mensagens PING e PONG);� busca de informação (mensagens QUERY e QUERY RESPONSE);� transferência de informação (mensagens GET e PUSH).

Em arquiteturas P2P estilo Gnutella um fator fundamental é o roteamento de queries.



Mensagem PING Mensagem PONG



Query (inundação) Query Response

Get/Push

03/09/2008

19


Arquiteturas Grid

Internet

Job

Job

Submissão remota de jobs

Mainframe

Computação em Grid

Do ponto de vista do usuário, o Grid é um processador virtual composto de dezenas/centenas de processadores interconectados.

Analogia: Power Grid (sistema elétrico de potência).


Arquiteturas Grid

Os elementos da arquitetura são recursos computacionais (CPU, armazenamento, hardware especializado, software, etc.).

Os recursos são estruturados em recursos virtuais e organizações virtuais (VOs) -- virtualização.

VOs são regidas por meio de SLAs (Service Level Agreements).

Pontos de interação são definidos entre VOs para fins de submissão de jobs, inquirição e notificação de status e coleta de resultados.

Arquiteturas Grid


Aplicação

Coordenação

Recurso

Conectividade

Recursos “locais”

Reserva AntecipadaGerência & MonitoramentoReplicação

ServiçosAPIs/SDKsMiddleware

IdentificaçãoRegistroDescoberta

Single-sign onAutorizaçãoDelegação

CPUArmazenamentoComunicação


Grid: Recursos Virtuais

Recursos

Serviços

Acesso

Armaze-

namentoSensores Aplicações InformaçãoComputadores

Interfaces dos Recursos

Interfaces Comuns

Classes de Interfaces

(c) Open Grid Forum

03/09/2008

20


Grid: Organizações Virtuais

Organização Real

Organização Virtual

SLA

SLA

Recurso


Grid X Conceitos Similares

Processamento Distribuído:� Fraco acoplamento;� Heterogêneo;� Intra/inter-organizacional, Pequena escala.

Processamento Paralelo (Cluster):� Forte acoplamento;� Homogêneo;� Intra-organizacional.

Grid:� Fraco acoplamento;� Heterogêneo;� Inter-organizacional, Larga escala.


Grid: Exemplo

Recursos

Virtualizados

Serviços

de Grid(middleware) Brokering

Service

Registry Service

DataService

Equipment Service

Job-Submit Service

ComputeService

Notify

Advertise

ApplicationService

(c) Open Grid Forum

1

2

3

4

5


Grid: Exemplo de Serviços� Compartilhamento de dados (Data Grids) - Exemplo: dados astronômicos.� Processamento (Computational Grids) - Exemplo: simulação.� Equipamentos especializados (Equipment Grids) - Exemplo: telescópio.

Aplicações desenvolvidas segundo uma arquitetura Grid devem utilizar uma infra-estrutura comum para disponibilização, gerência e uso dos serviços. Esta infra-estrutura pode consistir de um middleware, toolkit, ou ambiente de programação.

03/09/2008

21


Grid: Globus Toolkit

Conjunto de funções de suporte a arquiteturas Grid:� Gerência de execução (alocação e gerência de recursos, manutenção de workspace);� Comunicação (mensagem, RPC, estado compartilhado, I/O remoto providos pela Nexus Communication Library);� Gerência de Informação (publicação, descoberta e acesso a informação sobre serviços disponíveis no Grid);� Segurança (autenticação, autorização, delegação, gerência de credenciais).

http://www.globus.org


Grid: Globus Toolkit

(c) Globus Aliance


Grid: Open Grid Service Architecture (OGSA)� Arquitetura aberta orientada a serviço para computação em Grid em padronização

pelo Open Grid Forum.� Classes de serviços similar ao Globus.� Utiliza padrões XML existentes (WS-Security, WS-Policy, etc.) e padrões específicos para computação em Grid (Configuration Description Language (CDL), Job Submission Description Language (JSDL)).

http://www.ogf.org


Grid: OGSA

Security• Cross-organizational users• Trust nobody• Authorized access only

Information Services• Registry• Notification• Logging/auditing

Execution Management• Job description & submission• Scheduling• Resource provisioning

Data Services• Common access facilities• Efficient & reliable transport• Replication services

Self-Management• Self-configuration• Self-optimization• Self-healing

OGSA

OGSA “profiles”

Web services foundation

(c) Global Grid Forum

03/09/2008

22


Arquitetura Orientada a Serviço

Tal como em Grids, arquitetura orientada a serviço (SOA - Service- oriented Architecture) é uma solução de processamento distribuído inter-organizacional. O foco principal está na interoperabilidade e segurança (mesmo comprometendo a eficiência).

Um serviço encapsula uma lógica (de negócio) auto-contida, com interface bem definida e auto-descritiva, cuja execução não depende do contexto ou estado de execução de outros serviços.

Devido aos requisitos de interoperabilidade, implementações de SOA têm se limitado à tecnologia de serviços Web.


Arquitetura Orientada a Serviço

Os elementos da arquitetura são serviços.

Serviços são estruturados em serviços primitivos e compostos (composição de serviços).

Serviços compostos dependem dos serviços primitivos que os suportam.

Pontos de interação são definidos para registro, descoberta e invocação de serviços.


SOA: objetos X componentes X serviços

Objeto Componente Serviço

Granularidade baixa média alta

Acoplamento médio baixo baixo

Aspectos não- providos pelo providos pelo providos pelafuncionais programador container plataforma

Interoperoperabilidade protocolo protocolo protocoloespecífico específico XML

Composiçao embutida descritor de script deno código montagem composição

(ñ recursiva) (recursiva)


SOA: Características Próprias

Provedores e clientes de serviços podem trocar metadados sobre a utilização de serviços, por exemplo, políticas de uso do serviço.

Serviços são “sem estado” (stateless). Entretanto, o efeito da execução do serviço pode refletir em invocações subseqüentes (via alteração em base de dados, por exemplo).

Um serviços usualmente reflete um workflow balizado por regras de negócio.

Um serviço composto é também um serviço.

03/09/2008

23


SOA: Composição de Serviços

Composição é um fluxo de execução de serviços descrito por uma linguagem de composição (script descrevendo um workflow) e processado por uma máquina de composição. Tipicamente, linguagens de composição suportam:� execução sequencial e paralela de serviços;� variáveis (armazenam resultados intermediários);� pontos de decisão;� laços de iteração;� ações de compensação (tratamento de exceções).

Máquina deComposiçãoScript

ServiçoPrimitivo

ServiçoPrimitivo

...

conexão (partner link)Serviço

Composto


SOA: Orquestração X Coreografia

Coreografia descreve contratos inter-organizacionais para a execução de serviços. É um processo não necessariamente automatizado similar a um SLA.

Orquestração é um processo intra-organização, usualmente automatizado por meio de composição de serviços.

Coreografia

Orquestração


Desenvolvimento Orientado a Serviço

Usualmente empregam-se um processo multi-camadas:

Camada de negócio : representada por workflows, regras de negócio, políticas, etc.

Camada de serviço : representa as interfaces e conexões entre os serviços responsáveis pela lógica de negócio. Possui 3 subcamadas:� Serviços de orquestração (serviços criados via composição de serviços);� Serviços de negócio (serviços específicos do negócio);� Serviços de aplicação (serviços de propósito geral).

Camada de aplicação : plataformas de suporte a serviços e máquinas de orquestração.


Desenv. Orientado a Serviço

Camada deAplicação

Camada deServiço

Camada deNegócio

M.C M.C M.C

Plataforma

03/09/2008

24


SOA: Camada de Negócio

A camada de negócio utiliza editores dedicados para modelar processos de negócio. Estes editores geram scrips de composição.


SOA: Camada de Serviço

Serviços são descritos por meio de suas interfaces. O ciclo de desenvolvimento de um serviço segue o modelo clássico: definição de interface, compilação de interface, implementação da lógica de serviço.

Alternativamente, um serviço pode ser desenvolvido por meio de composição de serviços utilizando uma plataforma apropriada capaz de integrar as interfaces dos serviços primitivos, o script de composição, e código executável.

Uma vez desenvolvido, a interface do serviço pode ser registrada em um diretório de serviços.


SOA: Camada de Aplicação

A camada de aplicação utiliza utiliza plataformas e máquinas de composição. Plataformas oferecem facilidades de desenvolvimento de serviços via aplicativos, editores, debuggers, etc., bem como servidores onde os serviços serão instalados e diretórios onde os serviços serão registrados.

Máquinas de composição podem ou não ser integradas às plataformas.

Exemplos (produtos gratuitos):� Apache Axis: executa como aplicação no Tomcat (não possui editor ou máquina de orquestração, apenas aplicativos). Bom para o desenvolvimento de serviços primitivos.� Eclipse BPEL Project, Oracle BPEL Process Manager, ActivBPEL: Máquinas de orquestração. Bom para o desenvolvimento de serviços compostos.


SOA: Tecnologias Web

WS-BPELWS-CDL

WSDL, UDDI

SOAP, XML

HTTP, HTTPS

Codificaçãoe

Transporte

Descrição

Processode Negócio

Web Service Business Process Description LanguageWeb Service Choreography Description Language

Web Services Description LanguageUniversal Description, Discovery and Invocation

Simple Object Access ProtocolExtensible Markup Language

Hypertext Transfer Protocol (Secure)

WS-PolicyWS-Security

WS-Metadata

03/09/2008

25


SOA: Tecnologias & Produtos

WS-BPELWS-CDL

WSDL, UDDI

SOAP, XML

HTTP, HTTPS

WS-PolicyWS-Security

WS-Metadata

Contêiners(Ex: Tomcat + Axis)

Aplicativos & APIs(Ex: java2wsdl, jUDDI)

Máquinas de composição(Ex: ActivBPEL)

Arquiteturas Multi-Agentes


Elementos: agente, agência, localizador.

Agente: programa autônomo (fixo ou móvel) que possui sua própria thread de execução. Tipicamente executa o ciclo “monitora, processa, age”.

Agência: local onde agentes executam (por exemplo, processo).

Localizador: serviço que informa a localização de agências e agentes.

Arquiteturas Multi-Agentes


Interface Agência-Agente

InterfaceExterna da Agência

Interface Externado Agente

Agência

Agente

CriaAgenteDestriAgenteMigraAgente

Localizador

Interface doLocalizador Registra(agente/agencia)

Busca(agente/agencia)

GetEnv

Callback


Padrões Arquiteturais: Resumo

Padrão Elementos Estruturação Dependências Ponto de Int eração

Cliente/Servidor clientes e arbitrária clientes de prot. RPC entreservidores servidores clientes e servidores

Dirigida a Evento/ produtores e em torno de prods. e cons. prot. de interaçãoMensagem consumidores canais de difusão do canal c/ o canal

n-Tier clientes e camadas tier de tiers prot. de interaçãoservidores verticais (tiers) adjacentes entre tiers

Peer-to-peer pares redes nó dos nós prot. de cooperaçãoconectados entre pares

Grades recursos organizações orgs. de SLAs prot. de uso dosComputacionais virtuais virtuais estabelecidos recursos virtuais

Orientada a serviço composição serviço composto prot. de invocação eServiço de serviços dos primitivos composição de serviços

Multi-Agentes agentes e agentes contidos agentes de prot. de interaçãoagências em agências agências agente-agência e

agência-agência

IA844 Sistemas Distribuídos Redes e Sistemas Abertos...

Documents

Transcript of IA844 Sistemas Distribuídos Redes e Sistemas Abertos...