Sistemas Distribuídos Professor: Luiz José Hoffmann Filho

Processos- Threads,Virtualização Capítulo 3

Agenda Processos Threads –––– Threads e sistemas não distribuídos Threads e sistemas distribuídos Virtualização –––– Virtualização em sistemas distribuídos Arquiteturas de máquinas virtuais

Processos Sistemas operacionais modernos criam vários processadores virtuais, cada um para executar um programa Para monitorar os processadores virtuais o sistema operacional tem uma tabela de processos que contém entradas para armazenar valores de registradores de CPU, mapas de memória, arquivos abertos, etc.

Processos Processos: Programa em execução Sistema Operacional é responsável por assegurar que processos independentes não afetem (modos intencional, malicioso ou acidental) a correção do comportamento dos outros processos sendo executados Transparência no compartilhamento da mesma CPU e outros recursos de hardware

Processos Transparência implica em custo: – Criação de espaço de endereços completamente independente – Chavear a CPU entre dois processos – Salvar o contexto da CPU – Troca de informações entre disco e memória principal

Processos Em sistemas tradicionais, cada processo possui o seu próprio espaço de endereçamento e um único fluxo de execução

Processos No entanto, em alguns casos é desejável haver diversos fluxos de execução compartilhando um único espaço de endereçamento,ou seja, mesma região de memória

Único fluxo de execução ? Um servidor de arquivos deve esperar por requisições feitas ao disco. O fluxo de execução que fez a requisição é bloqueado aguardando a resposta. PERDA DE DESEMPENHO

Solução – Vários Fluxos de Execução Se o servidor de arquivos é implementado usando diferentes fluxos de execução, outras requisições de clientes podem ser processadas, enquanto o primeiro fluxo aguarda a resposta do disco MELHOR VAZÃO (THROUGHPUT) E GANHO DE DESEMPENHO

Processos versus Threads Thread PC Processos

Threads Cada um dos fluxos de execução de um processo é chamado de thread Threads podem ser vistas como mini-processos Cada thread executa sua própria porção de código Threads compartilham a CPU do mesmo modo que diferentes processos (timesharing)

Threads em sistemas não- distribuídos Threads que fazem parte de um mesmo processo não são independentes como o caso de diferentes processos TODOS threads em um mesmo processo possuem mesma região de memória, compartilhando as mesmas variáveis globais Um determinado thread pode ler, escrever ou mudar a pilha de dados de um outro thread Proteção deve ser feita pela 'aplicação'

Threads em sistemas não- distribuídos Threads podem estar em diferentes estados: executando, bloqueado, pronto ou finalizado Itens Por Thread PC Pilha Registradores Threads Filhas Estado Itens Por Processo Espaço de endereçamento Variáveis Globais Arquivos abertos Processos filhos Sinais Timers Informações da Conta Semáforos

Threads em sistemas não- distribuídos Principais Vantagens: 1) Explorar paralelismo ao executar um programa em um sistema multiprocessador Ex.: Cada thread é designado a uma CPU, enquanto dados compartilhados são armazenados em memória compartilhada 2) Grandes aplicações, desenvolvidas como um conjunto de programas cooperativos Evita chaveamento entre diferentes processos – devido comunicação através de Interprocess Communication (IPC)

Threads em sistemas não- distribuídos Threads → comunicação pode ser feita com a utilização de dados Compartilhados Chaveamento → espaço de usuário

Implementação de Threads em Sistemas não-distribuídos Implementação no nível usuário – Threads rodam sobre o runtime system – coleção de procedimentos que gerenciam as threads – Quando um thread executa uma chamada de sistema, 'dorme', opera um semáforo ou mutex, o runtime system verifica se o thread deve ser suspenso

Implementação de Threads em Sistemas não-distribuídos Implementação no nível de usuário Sistema Suporte SO

Implementação de Threads em Sistemas não-distribuídos Nível usuário – Custo da criação custo de alocar memória para a pilha – Chaveamento de contexto de thread pode ser feito em apenas algumas instruções: não há necessidade de mudar mapas de memória, descarregar o TLB (Translation Lookaside Buffer) »Ex.: Threads que precisam entrar em sincronia

Implementação de Threads em Sistemas não-distribuídos Desvantagem de threads de nível de usuário: – Problema está em como chamadas de sistemas bloqueantes são implementadas Ex.: ler um pipe vazio → chamada de sistema → bloqueio – Todos os threads são bloqueados !

Implementação de Threads em Sistemas não-distribuídos Implementação no kernel SO

Implementação de Threads em Sistemas não-distribuídos Implementação no kernel –––––– Criação, encerramento, sincronização deverão ser feitos pelo kernel Chamadas de sistema deverão ser realizadas Chavear contextos de threads é tão caro quanto chavear contexto de processos

Implementação de Threads em Sistemas Distribuídos Importante propriedade de threads é que eles podem proporcionar um meio conveniente de permitir chamadas bloqueantes de sistema sem bloquear o processo inteiro

Implementação de Threads em Sistemas Distribuídos Threads são particurlamente atraentes para utilização em sistemas distribuídos → facilitam muito expressar comunicação na forma de manter múltiplas conexões lógicas ao mesmo tempo

Clientes Multithreads Sistemas distribuídos que operam em redes de longa distância → escondem longos tempos de propagação de mensagens entre processos A maneira de ocultar latências de comunicação é iniciar a comunicação e imediatamente prosseguir com outra atividade

Clientes Multithreads – Browsers Web Documento Web consiste em: texto, imagens, ícones, etc. A cada elemento, browser estabelece uma conexão TCP/IP, para ler os dados e passar ao monitor do usuário Operações bloqueadoras: estabelecimento da conexão, leitura de dados

Clientes Multithreads – Browsers Web Browsers começam a exibir dados enquanto a medida em que novas informações chegam Enquanto o texto está sendo disponibilizado para o usuário, incluindo as facilidades de rolamento, p.ex., o browser continua buscando outros arquivos, como imagens Vantagem: usuário não precisa esperar até que todos os componentes sejam buscados

Clientes Multithreads – Browsers Web Browser como clientes multithread simplifica Threads separados são ativados para se encarregar de buscar diferentes partes de uma página Caso o servidor esteja em sobrecarga, ter um cliente multithread possibilita estabelecer conexões com diferentes servidores, permitindo transmissão dos dados em paralelo Cliente pode manipular fluxos de dados de entrada em paralelo → Threads!

Servidores Multithreads Servidor de arquivos normalmente espera pela entrada de uma requisição para uma operação de arquivo e, na sequência, executa a requisição e então devolve a resposta. Como aumentar o desempenho?

Servidores Multithreads Funcionamento de servidores multithreads: – requisições são enviadas por clientes para uma porta no servidor – Thread despachante lê requisições que entram para uma operação de arquivo – Servidor escolhe um thread operário – Se o thread escolhido estiver suspenso, outro thread é selecionado para ser executado: p.ex., o thread despachante pode ser selecionado para adquirir mais trabalho

Servidores Multithreads

Se o servidor é inteiramente CPU bound, não existe necessidade de diversos threads. Aumento de complexidade sem ganho de desempenho

Virtualização Threads e processos podem ser vistos como um modo de fazer diversas tarefas ao mesmo tempo Em computadores monoprocessador, execução simultânea é uma ilusão → única CPU, somente uma instrução de um único thread ou processo será executada por vez Virtualização de recursos: “fingir” que um determinado recurso está replicado no sistema

Virtualização Estende ou substitui uma interface existente de modo a imitar o comportamento de um outro sistema

Virtualização Na década de 1970 a virtualização foi aplicada com sucesso nos mainframes IBM, que ofereciam uma máquina virtual para executar softwares que incluiam aplicações e também os sistemas operacionais

Virtualização Softwares em nível mais alto são mais estáveis que o hardware e sistemas de software de baixo nível → virtualização pode ajudar transportando as interfaces de softwares para novas plataformas. Novas plataformas são capazes de executar softwares existentes anteriormente

Arquiteturas de máquinas virtuais Existem vários modos pelos quais a virtualização pode ser realizada na prática Existem quatro tipos diferentes de interfaces em quatro níveis diferentes

Virtualização Essência da virtualização é imitar o comportamento das interfaces (instruções de máquina, chamadas de sistema)

Virtualização Máquina virtual de processo Aplicações desenvolvidas para um SO são executadas em outro SO Virtualização feita somente para um único processo emuladores → imitar chamadas de sistema → Não é trivial

Virtualização Monitor de máquina virtual Fornece o conjunto de instruções completo do hardware Vários sistemas operacionais diferentes executando independente e concorrentemente na mesma plataforma Importantes no contexto de confiabilidade e segurança → isolamento de uma aplicação e seu ambiente → falhas não afetam a máquina inteira Ex.: VMware

Virtualização

Clientes

Cliente possui uma aplicação sendo executada para cada serviço remoto Exemplo: Agenda sendo executada no PDA de um usuário e que precisa entrar em sincronia com uma agenda remota, possivelmente compartilhada

Clientes Cliente possui acesso direto a serviços remotos usando apenas uma interface de usuário Exemplo: Máquina cliente não possui nenhuma informação para processamento, tornando-a independente da aplicação → clientes minimizados → facilidade de gerenciamento do sistema

● Clientes – Sistema X Window (1/4) Desenvolvido em 1984 no MIT, é uma das interfaces de usuário em rede mais utilizadas ● Usado para controlar terminais mapeados em bits ● Servidor distribui as ações de entrada do usuário (mouse e teclado) e aceita pedidos de saída através de vários programas clientes

● Clientes – Sistema X Window (2/4) Pode ser visto como a parte de um SO que controla o terminal ● Oferece uma interface de nível relativamente baixo, para controlar a tela e para capturar os eventos do teclado e do mouse → biblioteca Xlib ● Arquitetura Cliente-Servidor: núcleo X recebe requisições vindas de diversas aplicações sendo executadas.

Clientes – Sistema X Window (3/4)

● máquinas diferentes → protocolo X de comunicação ● Uma instância de Xlib pode trocar dados e eventos com o núcleo X ● Xlib pode enviar requisições ao núcleo X para criar ou encerrar uma janela, estabelecer cores e definir o tipo de cursor. O núcleo X reagirá a eventos locais como entrada de teclado e mouse devolvendo pacotes de eventos a Xlib. Clientes – Sistema X Window (4/4) Clientes podem rodar de forma transparente em

●●●●●● Servidores Questões gerais de projeto Iterativo ou Concorrente? Para onde os clientes enviam requisições? Como encerrar um serviço?

● Servidores Iterativo ou Concorrente? ●●●● Iterativo: O servidor é implementado através de um processo único, retirando a requisição do cliente e tratando-a Concorrente: O ´processo servidor´ não manipula a requisição propriamente dita, mas a passa para uma thread separada ou um outro processo.

● Servidores Para onde os clientes enviam requisições? ●●●●●●●● Requisições são enviadas a um processo servidor através de uma porta Para alguns serviços, são atribuídas portas padrão: HTTP 80, FTP 21, SSH 22 Em alguns casos, pode-se implementar um daemon, que ´escuta´ uma porta conhecida e redirecina a requisição para a porta do serviço No caso Unix, inetd

● Servidores Para onde os clientes enviam requisições?

● Servidores Como encerrar um serviço? ● Considere um usuário transmitindo um arquivo via ftp e que decide interromper o servidor para cancelar a transferência ●●●●●● Servidor encerra, após um tempo, a conexão Servidor possui uma conexão de controle Servidor trata, em uma mesma conexão, dados urgentes

● Servidores Manter ou não o estado de um cliente? ● Servidor sem estado: Não mantém informações sobre os estados de seus clientes e pode mudar o seu estado sem ter que informar a nenhum cliente ● Exemplos: Servidor Web, Servidor de arquivos

● Servidores Manter ou não o estado de um cliente? ● Servidor sem estado: Em alguns casos, servidores Web podem guardar informações dos clientes Podemos ter um servidor sem estado, que guarde informações de clientes, MAS ESTAS INFORMAÇÕES NÃO SÃO ESSENCIAIS PARA O FUNCIONAMENTO!!!

● Servidores Manter ou não o estado de um cliente? ● Servidor com estado: Mantém informações persistentes sobre os seus clientes. ● Exemplo: servidor de arquivos que permite um cliente manter cópia local de um arquivo → servidor guarda os clientes que têm permissão de mudanças no arquivo antes de atualizá-lo no localmente

Clusters de Servidores Conjunto de máquinas conectadas por uma rede, no qual cada máquina executa um ou mais servidores. Estas máquinas estão conectadas por uma rede local, com alta largura de banda e baixa latência.

Clusters de Servidores

Clusters de Servidores - Comutador Forma o ponto de entrada para o cluster de servidores, oferecendo um único endereço de Rede. Considerando TCP, o comutador aceita requisições e as transfere a um dos servidores Identifica o melhor servidor a tratar a requisição

Clusters de Servidores - Comutador

Clusters de Servidores Distribuídos Conjunto de máquinas que possivelmente muda dinamicamente, com vários pontos de acesso também possivelmente variáveis, mas se apresenta ao mundo externo como um única e poderosa máquina.

Clusters de Servidores Distribuídos Vários pontos de acesso Estabilidade no acesso Alto desempenho Flexibilidade

Migração de Código Em alguns casos é importante migrar código de uma máquina para outra Problema: como fazer esta tarefa em sistemas heterogêneos!

Por que Migrar Código? Principal razão: Aumento de Desempenho

Migração de Código - Desempenho Envio de processos de máquinas sobrecarregadas para máquinas com cargas mais leves Evitar grande quantidade de mensagens trocadas entre aplicações cliente-servidor: ●●●● Ex.1: operações de banco de dados que envolvem uma grande quantidade de dados(aplicação cliente → servidor) Ex.2: formulários enviados do servidor → cliente (applets)

Modelos para Migração de Código Migração de código é algo muito mais amplo: podemos também migrar status de um programa, sinais pendentes e outras partes do ambiente

Modelos para Migração de Código Processo consiste em três segmentos[Fuggeta et al 1998]: ●●●●●● Segmento de código: contém o conjunto de instruções que compõem o programa que está em execução Segmento de recursos: contém referências a recursos externos (arquivos, impressoras,outros processos, bibliotecas) Segmento de execução: armazenar o estado em execução de um processo no momento da migração (dados privados, pilha,contador de programa)

Modelos para Migração de Código Mobilidade pode ser de dois tipos: ●●●● Mobilidade Fraca: possível transferir somente o segmento de código, junto com alguns dados de inicialização. Requer somente que a máquina-alvo possa executar o código (portabilidade). Ex: applets Java Mobilidade Forte: segmento de execução também pode ser transferido. O processo em execução pode ser parado e movido para uma outra máquina e retomar a execução no ponto original. Mais geral, porém mais difícil de ser implementada

Modelos para Migração de Código Em relação do ponto de ínicio da migração: Iniciada pelo remetente: a migração é iniciada na máquina em que o código está em execução no momento em questão. Ex: enviar programa de busca pela Internet a um servidor de banco de dados para realização de pesquisas → agente móvel que passa de site para site Iniciada pelo destinatário: Iniciativa da migração de código é tomada pela máquina-alvo. Ex: Applets java

Modelos para Migração de Código

Migração e recursos locais Segmentos de recursos requerem uma atenção especial → O segmento de recurso nem sempre pode ser transferido junto com outros segmentos sem ser trocado Ex.: Comunicação de um processo sendo feita através de uma porta TCP. Ao mudar de localização, este processo deverá devolver a porta e requisitar uma nova no destino

Migração e recursos locais Três tipos de vinculações processo-recurso [Fuggetta et al, 1998]: ● Vinculação por identificador ● Processo requer exatamente o recurso referenciado (URL de um site) ● Vinculação por valor ●●●● É necessário somente um valor Se outro recurso fornece o mesmo valor, execução não é afetada (bibliotecas padronizadas) ● Vinculação por tipo ● Processo requer um recurso de um tipo específico (monitores, impressoras)

Migração e recursos locais Três tipos de vinculações recurso-máquina: ●●●●●● Recursos não ligados: recursos podem ser movidos com facilidade entre máquinas diferentes(arquivos de dados) Recursos amarrados: recursos podem ser movidos ou copiados, mas só a custo relativamente alto ( banco de dados locais) Recurso fixos: recursos estão intimamente vinculados a uma máquina ou ambiente especifico e não podem ser movidos → dispositivos locais

Migração em Sistemas Heterogêneos Migração em sistemas heterogêneos requer ●●●●●● Que o segmento de código possa ser executado em cada plataforma Que o segmento de execução possa ser adequadamente representado em cada plataforma Efeito global: Migrar sistema operacional inteiro, em vez de migrar processos