UNIVERSIDADE TECNOLÓGICA FEDERAL DO PARANÁ INTRODUÇÃO AOS SISTEMAS DISTRIBUÍDOS

Transcrição

1 PR UNIVERSIDADE TECNOLÓGICA FEDERAL DO PARANÁ INTRODUÇÃO AOS SISTEMAS DISTRIBUÍDOS Prof. Cesar Augusto Tacla 1

2 Sumário 1. INTRODUÇÃO a. Definição de sistemas distribuídos (SDs) b. Exemplos de sistemas distribuídos c. Tipos de aplicações distribuídas d. Vantagens e dificuldades dos SDs 2

3 Sumário 1 a Definição de sistemas distribuídos 3

4 Definição O que é um sistema distribuído? Rede de Comunicação 4

5 Definição Um sistema distribuído é uma coleção de computadores autônomos conectados por uma rede de comunicação que é percebida pelos usuários como um único computador que provê um serviço ou resolve um problema. (Tanenbaum & Steen, 2002) Esta definição faz referência a um conceito importante em sistemas distribuídos, o da transparência 5

6 Definição Um sistema distribuído é composto por computadores conectados em rede (hardware e software) que se comunicam e coordenam suas ações somente através do envio de mensagens. (Coulouris et al., 2001) 6

7 Sumário 1 b Exemplos de sistemas distribuídos 7

8 Exemplo 1: WEB % ISP intranet % % % WEB: Acesso remoto a páginas FTP: Transferência de arquivos backbone satellite link desktop computer: server: network link: Fonte: figura 1-1 (Coulouris et al., 2003) ISP: Internet Service Provider = provedor de acesso 8

9 SISTEMA BANCÁRIO 9

10 Exemplo 2: Bancos Caixas automáticos BD banco 1 BKP BD banco 1 BD = banco de dados BKP = backup Caixas automáticos BD banco 2 BKP BD banco 2 Fonte: 10

11 Aspectos importantes num sistema distribuído bancário: Acessos múltiplos (concorrentes) à mesma conta: vários usuários acessam a mesma conta ou um sistema do banco (emissão de relatórios) acessa ao mesmo tempo em que usuários realizam transações. Transações bancárias podem envolver contas armazenadas em diferentes bancos de dados ou localidades. 11

12 O serviço deve ser transparente ao usuário não interessa se os dados de sua conta estão armazenados no banco 1 ou banco 2, a aplicação não deve em nenhum momento deixar transparecer aspectos internos do sistema O serviço deve ser confiável (não deixa os objetos em estados inconsistentes) e seguro Bases de dados replicadas devem ser consistentes. Bases de dados replicadas: aumentam a tolerância a falhas, mas podem tornar o sistema não confiável! Tolerância a falhas 12

13 NAPSTER E SIMILARES 13

14 Exemplo 3: Napster usuário Servidor NAPSTER usuário Requisição de MP3 Anúncio usuário Transferência de arquivo usuário 14

15 Outros Exemplos Similares ao NAPSTER EMULE BITORRENT SKYPE (VoIP) MSN MESSENGER, YAHOO Outros APLICAÇÕES DE MULTIMÍDIA WEB conferência Difusão de streams on-line (voz, vídeo) 15

16 CLUSTER 16

17 Exemplo 4: Cluster (1) CLUSTERS ou AGRUPAMENTOS Máquinas conectadas por rede de alta velocidade Necessidade de alto desempenho computacional Evitar custo de máquinas de alto desempenho Objetivo: compartilhar recursos computacionais De processamento De armazenamento De memória Outros 17

18 Exemplo 4: Cluster (2) JAGUAR Cluster de máquinas do Oak Ridge National Laboratory (EUA) Terceiro da lista dos TOP 500 SUPERCOMPUTERS INSTALADO EM CORES Gflops FONTE Solução: agrupamento físico de máquinas de menor porte = cluster: mesmo espaço geográfico Normalmente dentro da mesma organização, com software/hardware homogêneos Tianhe-2, a supercomputer developed by China s National University of Defense Technology, retained its position as the world s No. 1 system with a performance of petaflop/s (quadrillions of calculations per second) cores 18/11/

19 Exemplo 4: cluster (3) Clusters são utilizados para... Aumentar a disponibilidade de serviço se um nodo falha, outro assume Equilibrar carga de trabalho um ou mais computadores do cluster atuam como distribuidores da carga entre os demais Alto desempenho Para resolver tarefas complexas que podem ser decompostas em sub-tarefas, cada uma rodando num nodo do cluster. Google Donates One Billion Core-Hours to Science 19

20 GRID OU GRADE 20

21 Exemplo 5: Grid (1) GRID ou GRADE = as máquinas encontram-se distantes geograficamente. É uma cooperativa de máquinas não pertencem necessariamente a mesma organização! são ditas organizações virtuais não há administração central dos recursos computacionais Utilização de protocolos/padrões abertos Quando as máquinas não pertencem a uma organização, alguns denominam esta forma de computação de computação voluntária (volunteer computing) 21

22 Exemplo 5: Grid (2) Aplicações Tarefas complexas decompostas Reunião dos resultados parciais Distribuição das tarefas pode ser feita em função de disponibilidade dos recursos, capacidade, desempenho, custo e QoS Exemplos de grids de pesquisa Laboratório Nacional de Computação Científica: Campina Grande: 22

23 Exemplo 5: Grid (3) Exemplos participação de qualquer usuário final Primeiro projeto (1996): GIMPS MERSENNE PRIME SEARCH busca pelo maior número primo de Mersenne (matemático/monge francês) Definição: quando 2 n -1 é um número primo ele é dito número primo de Mersenne. World Community Grid: Identificar quais defeitos em proteínas produzidas pelos genes humanos podem causar doenças Utiliza BOINC Xsede da universidade de Purdue XSEDE - the Extreme Science and Engineering Digital Environment 23

24 Continuação BBC Climate Change Experiment: Tentativa de prever o clima para o século 21 Utiliza BOINC Introdução: 24

25 CLUSTER X GRID 25

26 CLUSTER X GRID CLUSTER: conjunto de máquinas dedicadas Tipicamente agrupadas em um único local físico de uma mesma organização GRID: aproveitamento de recursos de máquinas ociosas De uma organização De voluntários (computação voluntária) Tanto clusters como grids necessitam de software para gerenciamento de carga: HTCondor BOINC (grid)

27 Softwares para gerenciamento de carga JOB SUBMETIDO PELO USUÁRIO WORKLOAD MANAGEMENT SOFTWARE CLUSTER OU GRID 27

28 Responder as questões de 0010-TAR1-GridCluster-questoes.txt 28

29 Sumário 1 c Tipos de aplicações distribuídas resolução distribuída sistemas multiagentes 29

30 RESOLUÇÃO DISTRIBUÍDA 30

31 RESOLUÇÃO DISTRIBUÍDA Resolução distribuída de problemas Um usuário deseja resolver um problema complexo (ex. renderização de imagens complexas) Decomposição de um problema em subproblemas pelo desenvolvedor de modo top-down Distribuição dos subproblemas para diferentes processos Um dos processos coleta e monta o resultado final T1 T1.1 T1.2 T1.3 31

32 RESOLUÇÃO DISTRIBUÍDA Sistemas Distribuídos/UTFPR Prof. Cesar Augusto Tacla 32

33 RESOLUÇÃO DISTRIBUÍDA Tempo Renderman da Pixar Filme 2 minutos 30 frames por segundo minutos de renderização No Distributed Render Environment (Grid da Universidade de Purdue): Filme 2 minutos 30 frames por segundo 36 minutos de renderização Fonte (TeraGrid Purdue) 33

34 SISTEMAS MULTIAGENTES 34

35 SMA Sistemas multi-agentes são sistemas abertos e heterogêneos onde vários desenvolvedores desenvolvem agentes, Agentes são software dotados de um certo grau de inteligência e, principalmente, de interação com outros agentes, capazes de interagirem e produzirem algum resultado útil ao usuário embora não tenha sido concebidos inicialmente com aquele objetivo específico. Fonte: 35

36 Exemplo integração de serviços RESERVA VEÍCULO SERVIÇOS WEB Empresa YY Empresa XX RECEBE INTINERÁRIO RESERVA HOTEL Hotel XX Hotel ZZ Hotel YY Hotel WW RESERVA PASSAGEM Locação XX Locação YY Locação ZZ CLIENTE DEBITA CARTÃO Instituição Financeira COMUNICA CLIENTE 36

37 SMA Em sistemas multiagentes, o foco na interação entre agentes (competição ou colaboração); i.e. solução surge através da interação Ex. leilão, simulações sociais Para simulações sociais, um bom início é a ferramenta de simulação NETLOGO Sistemas peer-to-peer são similares aos SMAs, há diferenças conceituais nos modelos de arquiteturas. SMA tem inspiração em modelos psico-sociológicos e cognitivos Ex. arquitetura BDI (Believes-Desires-Intentions) 37

38 PEER-TO-PEER P2P As vezes, é citada como uma arquitetura, porém, conceitualmente é mais do que isto! Preconiza a igualdade entre os participantes não há servidor, nem cliente todos são iguais. A rede é dos participantes. Vide manifesto: Exemplo de sistemas GNUTELLA (precursor) SNEER ( computação soberana 38

39 Sumário 1 d Vantagens e dificuldades dos SDs 39

40 Motivações Razões para construir um SD Desempenho MAIOR DO QUE sistema centralizado Distribuição natural das aplicações: bancárias, videoconf., etc. Robustez: frente a falhas Escalabilidade: sist. pode ser aumentado sem perda de desempenho? Compartilhamento de recursos Impressoras e outros hardwares Arquivos (inclusive páginas Web) CPU Memória Espaço em disco dados 40

41 Dificuldades O desenvolvimento de um sistema distribuído é mais complexo do que um centralizado HETEROGENEIDADE ABERTOS SEGUROS ESCALÁVEIS CONFIÁVEIS CONCORRÊNCIA TRANSPARÊNCIA Sistemas Distribuídos/UTFPR Prof. Cesar Augusto Tacla 41

42 Exemplo Baseando-se no exemplo da aplicação bancária mostrada no início destes slides e considerando que: Há acessos múltiplos (concorrentes) à mesma conta; Transações bancárias podem envolver contas armazenadas em diferentes bancos de dados (BD); Não interessa ao cliente se os dados de sua conta estão armazenados no BD1 ou BD2 pode-se concluir que as características importantes para este tipo de sistema são... (> próximo) 42

43 Exemplo Acessos múltiplos (concorrentes) à mesma conta: vários usuários acessam a mesma conta ou um sistema do banco (emissão de relatórios) acessa ao mesmo tempo em que usuários realizam transações. Transações bancárias podem envolver contas armazenadas em diferentes bancos ou localidades. O serviço deve ser transparente ao usuário não interessa se os dados de sua conta estão armazenados no banco de dados 1 ou 2, a aplicação não deve em nenhum momento deixar transparecer aspectos internos do sistema O serviço deve ser confiável e seguro Bases de dados replicadas devem ser consistentes (não apresentar dados conflitantes) Tolerância a falhas 43

44 HETEROGENEIDADE Lidar com diferentes Redes hardwares (computadores) sistemas operacionais Linguagens de programação Além de resolver os problemas de heterogeneidade, o middleware define um modelo computacional uniforme para a programação de aplicações distribuídas. PROTOCOLOS SIST. OPER. HARDWARE APLICAÇÃO DISTRIBUÍDA MIDDLEWARE PROTOCOLOS SIST. OPER. HARDWARE RMI RPC CORBA PLATAFORMA 44

45 ABERTOS O grau de abertura de um SD depende de: Facilidade de adicionar novos recursos De hardware De software: novos serviços ou re-implementação de antigos SD abertos baseiam-se em: Mecanismos de comunicação uniformes Especificados por organismos tais como OMG e IETF Ex. CORBA (OMG) Publicação de interfaces de serviços: para esconder a heterogeneidade de implementação dos serviços, as implementações devem aderir a uma forma de publicar as interfaces dos serviços 45

46 SEGURANÇA Segurança envolve: selar informações importantes enviadas através da rede (ex. criptografia de número de cartão de crédito) Identidade: garantir a autenticidade da fonte. Ex. um médico deseja acessar dados de pacientes de forma remota. É preciso assegurar que o usuário é realmente o médico. Ex. um usuário deseja comprar um livro pela Internet. É preciso assegurar a identidade da loja virtual - que realmente é uma loja e não vai fazer mal uso do cartão. Problemas: Indisponibilidade de serviço devido a ataques Segurança de código móvel (ex..exe anexados a s, applets) 46

47 ESCALABILIDADE Um SD é escalável se, ao adicionarmos novos recursos e/ou usuários, seu desempenho permanece satisfatório. Exemplos: Endereços IPv4 de 32 bits => IPv6 128 bits DNS, no início, era uma tabela => foi particionada e é tratada localmente contendo replicações. Técnicas para garantir escalabilidade: Replicação de dados Caching Replicação de serviços 47

48 Tratamento de falhas Falhas são normalmente parciais em SDs Dificilmente todos os componentes falham simultaneamente Detecção Mensagens corrompidas => checksum Crash de um servidor => nunca é certo se o servidor caiu, se a falha está no link ou se a rede está sobrecarregada Esconder falhas Se uma mensagem não chega no destino => retransmissão Dados podem ser escritos em dois discos, se um está danificado, utiliza-se a cópia. 48

49 Tratamento de falhas (2) Tolerância a falhas Exemplo: quando um navegador da Internet não consegue acessar um servidor ele não prende o usuário indefinidamente. Como tornar um sistema tolerante a falhas? Redundância pode tornar sistema tolerante a falhas Replicação de dados No serviço DNS cada entrada é replicada em pelo menos dois servidores Explorar rotas alternativas na Internet Maior tolerância a falhas aumenta a disponibilidade do sistema 49

50 Transparência O sistema deve ser visto pelo usuário e pelo programador como um todo e não como uma coleção de componentes Vários tipos de transparência Acesso: recursos locais e remotos são acessados através de operações idênticas Localização: permite acessar um recurso sem conhecimento de sua localização (ex. pela URL e não pelo IP) Replicação: múltiplas instâncias de um recurso podem ser utilizadas sem que isto seja explícito para usuários e programadores 50

51 TRANSPARÊNCIA Vários tipos (cont) Concorrência: vários processos podem acessar o mesmo recurso sem interferir na utilização um do outro nem no recurso. Ex: sistema de telefonia celular (emissor) Mobilidade: permite a movimentação de recursos e clientes dentro de um sistema sem afetar a operação 51

52 RESUMO SISTEMAS DISTRIBUÍDOS SÃO ÚTEIS PARA Melhorar desempenho Melhor adaptados a distribuição natural dos elementos Porém são complexos são inerentemente concorrentes devem ser confiáveis devem ser transparentes funcionar em plataformas heterogêneas Middlewares resolvem parte destes problemas 52