aula08 - home | instituto de computaÇÃo › ~bit › mc714 › aulas › aula08.pdf ·...

Prof. Luiz Fernando Bittencourt IC - UNICAMP

MC714Sistemas Distribuídos2° semestre, 2018

Prof. Luiz Fernando Bittencourt IC - UNICAMP

P2P• Chord, CAN – estruturadas/procedimentos

determinísticos• Não estruturadas / procedimentos aleatorizados• Superpeers

Prof. Luiz Fernando Bittencourt IC - UNICAMP

Arquiteturashíbridas• Combinam mais de um tipo de arquitetura, por ex.

cliente-servidor e P2P

• Exemplo: sistemas de servidor de borda• “Borda da rede” – fronteira entre as redes corporativas e a Internet,

como fornecido por um provedor de serviço de Internet (ISP).

• Fig. 51.

• Servem conteúdo e otimizam distribuição de conteúdo e de aplicação.

• Também comum em sistemas distribuídos colaborativos.

• Cliente-servidor utilizado para nós conectarem-se ao sistema, depois

utilizam esquema descentralizado.

Prof. Luiz Fernando Bittencourt IC - UNICAMP

Arquiteturashíbridas• Ex.: BitTorrent – sistema de download de arquivos.

• Fig. 40.

• Transfere pedaços (chunks - 256kb) de arquivos até completar o arquivo.

• Importante garantir colaboração.

• Usuário acessa diretório global – sites web –referências aos arquivos torrent.

Prof. Luiz Fernando Bittencourt IC - UNICAMP

BitTorrent• Torrent contém informações sobre rastreador

(tracker).• Servidor que mantém lista de nós ativos que tem o arquivo requisitado.• Ativo = transferindo algum arquivo para outro nó.

• Peer entrando em um torrent:• Não possui pedaços, mas obtém com o tempo.• Recebe do rastreador lista de peers daquele torrent e se conecta a

alguns (vizinhos).• Enquanto baixa, também faz upload.• Pode trocar os peers com quem realiza transferências.• Peer pode sair da rede assim que obtém arquivo inteiro.

Prof. Luiz Fernando Bittencourt IC - UNICAMP

BitTorrent• Requisição de pedaços:

• Peers diferentes têm subconjuntos diferentes de pedaços.

• Periodicamente, usuário requisita lista de pedaços de seus vizinhos.

• Em seguida, requisita pedaços faltantes de seus vizinhos – mais raro

primeiro.

• Enviando pedaços – “tit-for-tat”

• Usuário envia pedaços a vizinhos que estão enviando a ele com a maior

taxa.

• Outros peers param de receber dados desse usuário.

• Re-avalia os “top 4” a cada 10 segundos.

• A cada 30 segundos seleciona aleatoriamente outro peer e começa a

enviar pedaços.

• “Desafoga” de forma otimista esse peer.

• Novo peer pode se juntar ao “top 4”.

Prof. Luiz Fernando Bittencourt IC - UNICAMP

BitTorrent• Versões atuais suportam DHTs• Mainline DHT – baseado em Kademlia• rede “sem” trackers (ou com tracker distribuído).

Prof. Luiz Fernando Bittencourt IC - UNICAMP

ArquiteturasversusMiddleware

Prof. Luiz Fernando Bittencourt IC - UNICAMP

ArquiteturasversusMiddleware• Middleware é uma camada entre aplicações e plataformas

distribuídas.• Proporcionar transparência de distribuição: ocultar das aplicações, até

certo ponto, a distribuição de dados, processamento e controle.

• Sistemas de middleware, na prática, adotam estilo arquitetônico específico.• CORBA – objetos• TIB/Rendezvous – eventos

• Simplifica o projeto de aplicações.• Por outro lado, pode não ser o ideal para determinada aplicação.

Prof. Luiz Fernando Bittencourt IC - UNICAMP

ArquiteturasversusMiddleware• CORBA oferecia somente objetos que podiam ser invocados por

clientes remotos.• Muito restritivo.

• Foram adotados outros padrões de interação, como mensagens.

• Acrescentar características pode resultar em soluções inchadas.• Melhor ter soluções específicas adaptáveis a requisitos das aplicações.

Prof. Luiz Fernando Bittencourt IC - UNICAMP

ArquiteturasversusMiddleware• Middlewares simples de configurar, adaptar e personalizar

conforme necessidade da aplicação são desejáveis.• Sistemas atuais com separação mais estrita entre políticas e

mecanismos.• Vários mecanismos com os quais pode-se modificar comportamento

do middleware

Prof. Luiz Fernando Bittencourt IC - UNICAMP

Interceptadores• Interceptadores: pedaço de software que interrompe o fluxo de

controle usual e permite que outro código seja executado.

• Idéia básica de invocação remota em SDs com objetos:• Objeto A pode chamar método de um objeto B quando este está em

uma máquina diferente de A.

• Objeto A enxerga interface local que é a mesma oferecida por B; objeto A chama essa interface local.

• Chamada por A é transformada em invocação a objeto genérico através de uma interface geral de invocação oferecida pelo middleware.

• Invocação do objeto genérico é transformada em mensagem, que é enviada pela interface de rede do sistema local de A.

• Fig. 52.

Prof. Luiz Fernando Bittencourt IC - UNICAMP

Interceptadores• Chamada B.faz_alguma_coisa(valor) é transformada em uma

chamada genérica invoke(B, &faz_alguma_coisa, valor).

• Se B for replicado, interceptação pode ajudar• Interceptador de nível de requisição.

• Interceptador chama invoke para cada uma das réplicas.

• A não precisa estar ciente da replicação de B.• Middleware não precisa de componentes para tratar da chamada

replicada.• Apenas o interceptador de nível de requisição, que pode ser adicionado

ao middleware, precisa saber da replicação de B.

Prof. Luiz Fernando Bittencourt IC - UNICAMP

Interceptadores• Após invoke, uma chamada a objeto remoto deverá ser enviada

pela rede.• Interface do sistema deve ser invocada para envio de mensagem.

• Interceptador de nível de mensagem pode ajudar na transferência da invocação ao objeto visado.

• Ex.: valor é um conjunto grande de dados, melhor fragmentar.• Middleware não precisa estar ciente da fragmentação.

Prof. Luiz Fernando Bittencourt IC - UNICAMP

Softwareadaptativo• Interceptadores são na verdade um meio de adaptar o middleware.• ambiente dinâmico (mobilidade, variância no QoS, problemas de

hardware, bateria) à necessidade de adaptação.• Peso da adaptação colocado no middleware ao invés de em toda

aplicação.• Software adaptativo no middleware para tratar influências do

ambiente.• Menos sucesso que o esperado.• Entretanto, considerado um aspecto importante em SDs modernos.

Prof. Luiz Fernando Bittencourt IC - UNICAMP

Softwareadaptativo• Três técnicas para adaptação de software:• Separação de interesses.• Reflexão computacional.• Projeto baseado em componente.

Prof. Luiz Fernando Bittencourt IC - UNICAMP

Softwareadaptativo• Separação de interesses:• Modo tradicional de modularizar: separar partes que implementam

funcionalidade das que cuidam de outras coisas (funcionalidades extras – confiabilidade, desempenho, segurança, etc.)

• Middleware é em grande parte um manipulador de funcionalidades extras.

• Problema: não é fácil separar essas funcionalidades por meio de modularização.• Segurança em módulo separado não funciona.• Como isolar tolerância a falhas em serviço independente?• Software orientado a aspecto: separar e entrelaçar esses interesses

cruzados em um sistema distribuído.

Prof. Luiz Fernando Bittencourt IC - UNICAMP

Softwareadaptativo• Reflexão computacional:• Capacidade de um programa inspecionar a si mesmo e, se necessário,

adaptar seu comportamento.

• Embutida em linguagens de programação.

• Alguns middlewares oferecem meios para aplicar técnicas reflexivas.

• Assim como orientação a aspecto, ainda não é largamente implantado em sistemas distribuídos.

Prof. Luiz Fernando Bittencourt IC - UNICAMP

Softwareadaptativo• Projeto baseado em componentes:• Permite que sistema seja configurado de forma estática ou em tempo

de execução.• Configuração dinâmica requer suporte a ligação tardia.

• Permite selecionar automaticamente melhor implementação de um componente em tempo de execução.

• Ainda complexo para sistemas distribuídos.• Substituição de um componente implica saber que efeito terá sobre

outros componentes distribuídos.

Prof. Luiz Fernando Bittencourt IC - UNICAMP

Softwareadaptativo• Busca continua por software adaptativo em SDs: não há método ou

implementação amplamente aceita.

• Argumento para suportar software adaptativo em sistemas distribuídos: muitos SDs não podem ser desligados.• SDs devem ser capazes de reagir a mudanças em seu ambiente, como

trocar dinamicamente políticas de alocação de recursos.

Prof. Luiz Fernando Bittencourt IC - UNICAMP

Autogerenciamento emSistemasDistribuídos

Prof. Luiz Fernando Bittencourt IC - UNICAMP

AutogerenciamentoemSDs• Para suportar maior quantidade de aplicações, SDs devem blindá-

las de aspectos indesejáveis das redes.• Necessidade de adaptação do comportamento (não de seus

componentes) de SDs em tempo de execução.• Organização dos componentes:• Fazer monitoração.• Ajustes automáticos.• Decidir onde são executados processos que manipulam a adaptação.

• Computação autonômica (ou sistemas auto): sistemas de realimentação de controle de alto nível que permitam adaptação automática a mudanças.

Prof. Luiz Fernando Bittencourt IC - UNICAMP

AutogerenciamentoemSDs• Sistemas auto:• Auto-gerenciador• Auto-reparador• Auto-configurador• Auto-otimizador

• Auto-gerenciador: termo genérico para englobar suas variantes.

Prof. Luiz Fernando Bittencourt IC - UNICAMP

Realimentaçãodecontrole• Existem diversas visões de sistemas auto-gerenciadores.• Em comum: adaptação ocorre através de um ou mais laços de

realimentação de controle.• Fig. 53.• Núcleo: componentes a serem gerenciados.• Guiados por parâmetros de entrada que podem ser controlados.• Porém, podem também ser influenciados por perturbações ou

ruídos, i. e., entradas não controláveis.• Perturbações: frequentemente advindas do ambiente do SD, mas

podem vir de interações não previstas de componentes.

Prof. Luiz Fernando Bittencourt IC - UNICAMP

Realimentaçãodecontrole• Três elementos que formam o laço de realimentação de controle.

• 1. O sistema a ser monitorado

• Vários aspectos do sistema precisam ser medidos.

• Dados: medição e estimação. Medição pode ser difícil ou pode

acarretar interferência na própria medição (p.ex. princípio da incerteza

de Heisenberg / Gato de Schrödinger).

• 2. Componente de análise de realimentação

• Analisa medições e as compara com valores de referência.

• Algoritmos que decidem possíveis adaptações.

• 3. Mecanismos para influenciar o comportamento do sistema.

• Colocação de réplicas, mudança de prioridade de escalonamento, troca

dinâmica de serviços, movimentação de dados, redirecionamento, etc.

• Acionados pelo componente de análise (este, ciente dos mecanismos e

seus efeitos).

Prof. Luiz Fernando Bittencourt IC - UNICAMP

Realimentaçãodecontrole• Obs: laço de realimentação de controle também se ajusta ao

gerenciamento manual.• Diferença é, justamente, a automatização do componente de análise.

• De uma forma ou outra, precisa-se de monitoração decente, assim como mecanismos decentes para controlar comportamento do sistema.

• Algoritmos para análise dos dados e ações corretas são dificuldade no desenvolvimento de sistemas auto-gerenciadores.

• Organização lógica (Fig. 53) pode ser diferente da organização física.• Componente de análise pode ser distribuído, por exemplo.• Monitoração em cada máquina.

Prof. Luiz Fernando Bittencourt IC - UNICAMP

Resumo

Prof. Luiz Fernando Bittencourt IC - UNICAMP

Resumo• Arquitetura de software e arquitetura de sistema• Organização lógica

• Organização física

• Estilo arquitetônico (software)• Princípio básico que é seguido na organização da interação entre os

componentes

• Camadas, orientação a objetos, orientação a eventos, orientação a espaço de dados

• Organização física• Cliente-servidor: certo grau de centralização.

• Arquiteturas descentralizadas: P2P/rede de sobreposição estruturada ou não estruturada.

• Sistemas auto-gerenciadores: até certo ponto fundem idéias de arquitetura de sistema e software. Laços de realimentação e controle e ajuste automático do comportamento.

Prof. Luiz Fernando Bittencourt IC - UNICAMP

Processos

Prof. Luiz Fernando Bittencourt IC - UNICAMP

Processos• Processo: um programa em execução no sistema operacional.• Importante: gerenciamento e escalonamento.

• Em sistemas distribuídos:• Cliente-servidor: conveniente usar multi-threading.

• Permitem clientes e servidores construídos de modo que comunicação e processamento se sobreponham.

• Virtualização / máquinas virtuais.

• Migração de processos / migração de código.

Prof. Luiz Fernando Bittencourt IC - UNICAMP

Processosethreads• Granularidade oferecida pelos SOs• Processos

• Pode ser refinada• Threads.

• Facilita construção de aplicações e melhora no desempenho.

Prof. Luiz Fernando Bittencourt IC - UNICAMP

Processosethreads• SO cria vários processadores virtuais• Cada um executa um programa

• Controle através de tabela de processos• Valores de registradores de CPU

• Mapas de memória

• Arquivos abertos

• Privilégios

• Etc.

• Processo: um programa em execução à programa sendo executado em um dos processadores virtuais do SO

Prof. Luiz Fernando Bittencourt IC - UNICAMP

Processosethreads• SO toma conta para não haver interferência, intencional ou não,

entre processos.

• Compartilhamento concorrente de CPU (e outros recursos) é

transparente.

• SO requer suporte de hardware para essa separação.

• Criar processos

• Criar espaço de endereço independente.

• Inicializar segmentos de memória (zerar, copiar dados).

• Pilha para dados temporários.

• Chaveamento entre processos:

• Salvar contexto de CPU (registradores, contador de programa, ponteiro

de pilha).

• Modificar registradores do gerenciamento de memória.

• Invalidar caches da TLB.

Prof. Luiz Fernando Bittencourt IC - UNICAMP

Processosethreads• Thread: sua própria porção de código, independente de outras

threads.• Sem esforço para oferecer transparência de concorrência.• Controle guarda informação mínima necessária ao compartilhamento

de CPU.• Contexto de thread = contexto de CPU + algumas informações para

gerência de threads.• Ex.: monitorar exclusão mútua para não dar tempo de CPU a uma

thread bloqueada.• Proteger dados contra acesso inadequado é tarefa do

desenvolvedor da aplicação multithread.

Prof. Luiz Fernando Bittencourt IC - UNICAMP

Processosethreads• Monothread: chamada que bloqueia, bloqueia qualquer ação do

processo.

• Multithread: pode-se separar o processo em threads que podem executar de forma independente.• Torna possível explorar paralelismo ao executar em multiprocessador;

cada thread em uma CPU.

• Pode executar também em um sistema monoprocessado, talvez leve mais tempo.

• Cada vez mais importante com processadores multicore baratos.

• Aplicações grandes multiprocesso:• Comunicação entre processos demanda intervenção do núcleo em

chamadas de sistema e chaveamento de contexto entre processos.

• Com threads, minimiza overhead já que tudo acontece no espaço do usuário.

Prof. Luiz Fernando Bittencourt IC - UNICAMP

Threads• Duas abordagens• Modo de usuário.• Núcleo ciente, com escalonamento.

• Modo de usuário (user thread)• Criar e terminar threads é mais barato• Alocar/liberar memória para pilha de threads• Chaveamento de contexto com poucas instruções

• Troca de valores de registradores de CPU• Não precisa mudar mapas de memória, limpar TLB, etc.• Necessário para sincronização

• Núcleo (kernel thread)• Perde vantagens da thread, oferece melhor escalonamento quando

bloqueios em threads acontecem.

Prof. Luiz Fernando Bittencourt IC - UNICAMP

Threads• Solução intermediária: Lightweight processes (LWP).• Processos que compartilham recursos • Espaço de endereçamento, páginas de memória física, sinalização e

manipuladores de arquivos).• Evita troca de contexto.

• Pode ser visto como uma CPU virtual disponível para executar código ou chamadas de sistema.

• LWP roda sobre uma kernel thread.• Fig. 54

Prof. Luiz Fernando Bittencourt IC - UNICAMP

LWP• LWP + threads no espaço do usuário• Criar, destruir e sincronizar threads é barato, sem intervenção do

núcleo.• Se processo tem LWPs suficientes, chamada bloqueante não

suspenderá processo inteiro.• Independentes de aplicação.• Facilidades para multiprocessamento (LWP à processador).

Prof. Luiz Fernando Bittencourt IC - UNICAMP

ThreadsemSDs• Threads atraentes• Manipular diversas comunicações lógicas• Permitir progresso da aplicação

• Cliente• Esconder atrasos de comunicação.• Iniciar comunicação e prosseguir com processamento independente.• Ex. browsers web.

Prof. Luiz Fernando Bittencourt IC - UNICAMP

ThreadsemSDs• Servidor• Simplifica código.• Facilita desenvolvimento paralelo.

• Ex: servidor de arquivos• Com thread vs. sem threads

• Fig. 55