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
Top Related