SD - parte 1 - fundamentos - Universidade Federal de Campina

Download Report

Transcript SD - parte 1 - fundamentos - Universidade Federal de Campina

Sistemas Distribuídos

Fundamentos

Nazareno Andrade Universidade Federal de Campina Grande 02/2008

Fundamentos Coordenando processos Construíndo sistemas Sistemas construídos 2

Fundamentos – O que são sistemas distribuídos – Para que distribuímos sistemas – Referências de sistemas distribuídos – Vocabulário sobre sistemas distribuídos – Arquiteturas de sistemas distribuídos – Modelos de sistemas distribuídos Coordenando processos Construíndo sistemas Sistemas construídos 3

Objetivos

Idéia clara do que são sistemas distribuídos – Propósito – Vantagens & desvantagens Repertório de sistemas Visão de questões de projeto 4

Que sistemas distribuídos nós usamos?

5

O que é um sistema distribuído?

6

Em comum:

Componentes independentes Canais de comunicação Imagem única Hardware independente + software unificando 7

“Conjunto de computadores independentes que se apresenta a seus usuários como um sistema único e coerente” Tanenbaum “Sistema em que componentes de hardware e software localizados em diferentes computadores interconectados se comunicam e coordenam suas ações trocando mensagens” – CDK “Sistema onde você não consegue trabalhar por causa de uma falha em um computador que você nunca viu” – Lamport 8

Por que sistemas distribuídos?

Compartilhamento – Documentos, impressoras, telescópios, ...

Escalabilidade – Mais carga → Mais recursos Custo x benefício – Um PC: dinheiro em dobro ≠ desempenho em dobro Robustez – Redundância Limitações da Física – Corpos se movem – Corpos não se movem rápido o suficiente 9

E nós, projetistas?

Concorrência Canais de comunicação Falhas parciais Descoberta de recursos Coordenação 10

Fundamentos – O que são sistemas distribuídos – Para que distribuímos sistemas – Referências de sistemas distribuídos – Vocabulário sobre sistemas distribuídos – Arquiteturas de sistemas distribuídos – Modelos de sistemas distribuídos Coordenando processos Construíndo sistemas Sistemas construídos 11

Sistemas de arquivos distribuídos: NFS

Compartilhar arquivos, compartilhar um servidor 12

Web

http://www.google.com

Google LSD http://lsd.ufcg.edu.br/~nazareno/xpto.html

Compartilhamento de documentos (ao menos inicialmente) Navegadores e servidores HTTP 13

Sistemas N-camadas

Apresentação Banco de dados Lógica Amazon, Google e quase todo e-commerce que você vir poraí...

Tecnologia popular: LAMP - Linux, Apache, MySQL, Perl/PHP/Python 14

Computação paralela: clusters

Alta performance, computação paralela Processamento numérico, processamento de dados, ...

Tecnologias: PBS, Bewuolf, MapReduce, Hadoop 15

Computação paralela: grids/grades

Domínios administrativos Alto desempenho, plataforma mais ampla, compartilhamento Tecnologias: Globus, Condor, OurGrid 16

Computação entre-pares, peer-to-peer

Compartilhamento, “bordas” da rede Gnutella, Kazaa, BitTorrent, Skype, MSN, ...

17

Computação pervasiva / ubíqua

Computadores estão em todo lugar, e conectados Celulares, carros, marcapassos, ...

18

Imagem única

transparência

19

Fornecendo uma imagem única

Transparência

Acesso Localização Migração Relocação Replicação Concorrência Falha

O que é

Escondemos se recursos são remotos Escondemos onde eles estão Escondemos se eles mudam de máquina Escondemos se eles se movem Escondemos redundância Escondemos compartilhamento Escondemos falhas 20

Embora isso não seja tão simples

Heterogeneidade – Plataforma, clientes, conexões Sistemas abertos – Diversas implementações de clientes Segurança – Nos componentes, nas comunicações, DoS Escalabilidade – Evitar gargalos Tolerância a Falhas – Componentes devem lidar com falhas dos demais Concorrência – Concorrência é a norma 21

Alguns princípios de projeto de SD

22

Transparência

Transparência para programa, usuário ou programador?

Envolve ao menos: Nomes lógicos – http://www.google.com

– Réplicas têm mesmo nome lógico Exclusão mútua distribuída – Lembram de SO?

Eficiência na comunicação Transparência é um contínuo, e não binário Transparência limitada pode ser necessária ou útil – A Física impõe limites – O usuário pode entender melhor o que está acontecendo 23

Desempenho

Medido através de métricas: – Vazão (throughput) – Tempo de resposta (response time, makespan) – Latência – Utilização dos recursos (nem sempre são independentes...) O custo da comunicação em geral é importante 24

Desempenho e comunicação

Em geral, queremos minimizar comunicação – Overhead de comunicação >> outros overheads • Canais são recurso mais escasso no sistema – Comunicação == tamanho e freqüência de mensagens Granulosidade do paralelismo (parallelism granularity) – Fine granularity – grãos pequenos  comunicação freqüente – Coarse granularity – grãos grandes  infreqüente comunicação 25

Escalabilidade

Existem SDs em 2, 10 e 10^6 computadores – Google, Amazon EC2, Skype, ...

Métodos para construir sistemas pequenos podem não valer para outras escalas Escalabilidade == É possível alterar a escala do sistema – Quantidade de usuários ou recursos (custo x benefício) – Escala geográfica – Manter o sistema gerenciável a medida que cresce Em geral depende de não haver gargalos  descentralização 26

Escalabilidade: por que não é simples

Escalabilidade  Descentralização Descentralização  Complexidade Princípios de algoritmos descentralizados escaláveis: – Nenhum componente tem informação sobre todo o sistema – Componentes tomam decisões baseadas em informações locais – Falhas parciais não inviabilizam resultado – Não há um relógio global único • Há aproximações bem imperfeitas, como o NTP 27

Mais sobre escalabilidade e o mundo real Duas lições recentes 1. Quando a escala é grande o suficiente, qualquer coisa acontece – Mensagens de controle corrompidas na Amazon e no PlanetLab 2. Ações coordenadas de componentes podem ser catastróficas – Problema do Skype em 2008 28

Heterogeneidade

Hardware independente  Configurações independentes Como sempre: níveis de indireção Neste caso,

middleware

29

Confiabilidade

Confiabilidade = disponibilidade + integridade + segurança Um sistema distribuído pode ser mais confiável que um monolítico – Tolerância a falhas parciais Um sistema distribuído não é necessariamente mais confiável – Falhas independentes?

– Segurança agora de diversos pontos – Integridade mais complexa Como resolver tudo isso? Neste curso!

30

Recapitulando

Transparência Desempenho Escalabilidade Heterogeneidade Confiabilidade Vamos usar bastante isso durante o curso...

31

Ciladas em projetos de SD

32

Não assuma que

A rede é confiável A rede é segura A rede é homogênea A topologia da rede não muda A latência é zero A largura de banda é infinita O overhead de transporte é zero Há um só administrador 33

Fim da introdução

34

Recapitulando...

• O que são sistemas distribuídos • Por que distribuir um sistema • Visão geral dos tipos de sistemas distribuídos • Objetivos comuns no projeto de sistemas distribuídos • Desafios particulares nesse projeto • O que não assumir Em resumo: o que sistemas distribuídos têm de particular 35

Mais sobre esse assunto

End-to-end arguments in computer design – Onde devem ficar as funcionalidades?

A note on distributed computing – Quão transparente deve ser a distribuição para o programador?

36

Cenas do próximo capítulo

Quais as formas de dividir responsabilidades em um SD? Qual o espaço de projeto?

– Centralizado, descentralizado, peer-to-peer, híbridos...

Como estudamos um sistema distribuído analiticamente?

– Modelos, dimensões úteis de SDs, resultados...

37