3.

Suporte de Sistemas de Operação para Sistemas Distribuídos
Fernando Silva
DCC-FCUP

Fernando Silva (DCC-FCUP)

3. Suporte de Sistemas de Operação para Sistemas Distribuídos

1 / 21

Agenda
Suporte necessário para middleware e Sistemas Distribuídos Implementação de threads Virtualização Clientes Servidores Servidores cluster

Referência: slides e cap. 3 do livro de Andrew Tanenbaum e Maarten van Steen.

Fernando Silva (DCC-FCUP)

3. Suporte de Sistemas de Operação para Sistemas Distribuídos

2 / 21

Suporte de Sistemas de Operação para Sistemas Distribuídos 3 / 21 .Suporte necessário para middleware e SD Os sistemas operativos desempenham um papel fundamental no suporte ao funcionamento dos sistemas distribuídos: Coordenam recursos básicos como: processos. que garante protecção dos recursos usados pelas aplicações processamento concorrente de aplicações Acesso a uma rede de comunicação Fernando Silva (DCC-FCUP) 3. disco. comunicação Fornecem uma API de programação para acesso aos recursos. memória.

Processos (1) Os processos são um construtor fundamental para os sistemas distribuídos. Processo .programa em execução (um fluxo de execução) caracterizado por um espaço de endereçamento e um contexto (ambiente de execução e estado do processo guardado em registos e memória) Troca de contexto sempre que o SO comuta a execução de dois processos tem custos óbvios (overheads) Fernando Silva (DCC-FCUP) 3. Suporte de Sistemas de Operação para Sistemas Distribuídos 4 / 21 .

Processos e Threads A função de um SO é tornar transparente a execução de múltiplos processos que concorrem pela partilha do mesmo CPU. só que tem custos: gestão segmentos de memória independentes overheads das trocas de contexto swapping de processos entre memória e disco O que é necessário? possibilitar ter vários fluxos de execução comutação rápida e de baixo custo entre os vários fluxos de execução Solução: threads Fernando Silva (DCC-FCUP) 3. Suporte de Sistemas de Operação para Sistemas Distribuídos 5 / 21 .

g. nos clientes) Fernando Silva (DCC-FCUP) 3. nos servidores) melhorar usabilidade (e.Threads versus múltiplos processos Criação e destruição de threads é muito mais eficiente do que com processos criação é aproximadamente 10-20 vezes mais eficiente Threads de um processo: partilham o mesmo espaço de endereçamento trocas de contexto entre threads realizadas sem intervenção do OS (5-50 vezes mais eficiente) partilham dados e outros recursos não estão protegidos uns dos outros Uso de múltiplos threads permite usar concorrência para esconder a latência da comunicação melhorar desempenho (e. Suporte de Sistemas de Operação para Sistemas Distribuídos 6 / 21 .g.

Soluções complicadas. como suportar sinalização de eventos? Fernando Silva (DCC-FCUP) 3. então todo processo bloqueia.Implementação de threads (1) Deve a implementação ser feita a nível do kernel do SO ou em software no nível do utilizador? User-level: todas as operações podem ser internas a um único processo ⇒ resulta em implementações muito eficientes todos os serviços fornecidos pelo kernel são concretizados em nome do processo onde reside o thread ⇒ se o kernel decidir bloquear o thread. interessam-nos os threads para lidar com eventos externos (bloqueiam com base no evento) ⇒ se o kernel não os distingue. Suporte de Sistemas de Operação para Sistemas Distribuídos 7 / 21 .

outro thread do mesmo processo. problema: perde-se eficiência porque cada operação de um thread requer passagem (trap) da aplicação para o kernel. fácil de lidar com eventos externos: o kernel (que apanha todos os eventos) selecciona para execução o thread associado ao evento.Implementação de threads (2) Kernel-level: operações de bloqueio de threads não constituem problema: o scheduler selecciona para execução. Conclusão: abordagens híbridas user-level e kernel-level. Fernando Silva (DCC-FCUP) 3. Suporte de Sistemas de Operação para Sistemas Distribuídos 8 / 21 .

Implementação de threads (3) Solaris threads são um exemplo de modelo híbrido.com todas as operações e sincronização sem intervenção do kernel os LWPs têm o seu scheduler e partilham uma tabela de threads sincronizam no acesso à tabela.processos leves que executam no contexto de um processo (no kernel) user-level threads . sem suporte do kernel executam operações bloqueantes pelos threads em modo kernel Thread state User space Thread Lightweight process Kernel space LWP executing a thread Fernando Silva (DCC-FCUP) 3. Light-Weight Processes (LWP) . Suporte de Sistemas de Operação para Sistemas Distribuídos 9 / 21 .

imagens) cada objecto ou ficheiro é carregado por um thread distinto. cada um através de um pedido HTTP (bloqueante) o browser vai visualizando os ficheiros à medida que estes vão chegando. Clientes multithreaded . Fernando Silva (DCC-FCUP) 3.objectivo é sobrepor comunicação e processamento Exemplo: cliente Web multithreaded (browser) ao carregar uma página HTML. propriedade excelente para expressar comunicação mantendo múltiplas ligações lógicas em simultâneo.Concorrência em SDs: clientes Os threads permitem satisfazer chamadas de sistema bloqueantes sem bloquear o processo que executa os threads. o browser analisa-a e verifica que é necessário carregar outros objectos (e.g. Suporte de Sistemas de Operação para Sistemas Distribuídos 10 / 21 .

Concorrência em SDs: servidores Objectivo é melhorar o desempenho e estrutura. múltiplos threads para atender pedidos reagir a novos pedidos enquanto anteriores estão a ser satisfeitos mapeável em sistemas multiprocessador (ou multicore) programas de compreensão mais simples Modelo dispatcher/worker (figura) Fernando Silva (DCC-FCUP) 3. Suporte de Sistemas de Operação para Sistemas Distribuídos 11 / 21 .

Suporte de Sistemas de Operação para Sistemas Distribuídos 12 / 21 . pois permite que os sistemas sejam independentes do hardware sejam facilmente portáveis e o código migrável fiquem isolados de falhas ou ataques a componentes suportem legacy software No essencial. Program Interface A Program Interface A Hardware/software system A (a) Fernando Silva (DCC-FCUP) Implementation of mimicking A on B Interface B Hardware/software system B (b) 3.Virtualização A virtualização de recursos é cada vez mais importante. a virtualização permite substituir interfaces existentes de modo a imitar o comportamento de outro sistema.

Java VM) VM Monitor (b): camada independente de software que imita o conjunto de instruções do hardware ⇒ permite a execução concorrente e independente de múltiplos SOs (E. VirtualBox) Fernando Silva (DCC-FCUP) 3. Suporte de Sistemas de Operação para Sistemas Distribuídos 13 / 21 . VMware. Xen.g.g.Implementações da virtualização (1) Process virtual machine (a) vs Virtual machine monitors Application Runtime system Runtime system Runtime system Operating system Hardware (a) Applications Operating system Operating system Operating system Virtual machine monitor Hardware (b) Process VM (a): um program é compilado para código intermédio (portável) que é executado por um emulador (E.

mouse.Clientes: interfaces com utilizador A grande maioria do software do lado do cliente é orientado para as interfaces gráficas com o utilizador (cada vez mais temos thin-clients).) Interfaces mais modernas permitem interacção com a aplicação (documentos compostos) ⇒ comunicação entre aplicações.g. mover o ícone do ficheiro para o cesto do lixo) in-place editing: integração de várias aplicações na interface (e. Suporte de Sistemas de Operação para Sistemas Distribuídos 14 / 21 . processamento de texto e desenho) Fernando Silva (DCC-FCUP) 3. etc.g. drag-and-drop: movimento de objectos pode originar interacção com outras aplicações (e. Application server Window manager Xlib Local OS Application server Application Xlib interface User's terminal Xlib Local OS X protocol X kernel Device drivers Terminal (includes display keyboard.

Software do lado do cliente Mais do que apenas interface com utilizador. caixas registadoras. etc. transparência na falha: tentativas automáticas de ligação para o mesmo ou outro servidor Client machine Client appl. TV powerboxes. Software embebido nas ATMs. Suporte de Sistemas de Operação para Sistemas Distribuídos 15 / 21 . Inclui componentes para alcançar transparência na distribuição transparência no acesso: stubs para RPC transparência na localização/migração: cliente conhece localização do servidor e é informado se esta mudar transparência na replicação: múltiplas invocações pelo stub do client. pode incluir processamento local e comunicação. Server 1 Server appl Server 2 Server appl Server 3 Server appl Client side handles request replication Replicated request Fernando Silva (DCC-FCUP) 3.

Na prática. i. fornecem vários serviços independentes (e.g. ftp-data ftp telnet smtp login sunrpc courier 20 21 23 24 25 49 111 530 File Transfer [Default Data] File Transfer [Control] Telnet any private mail system Simple Mail Transfer Login Host Protocol SUN RPC (portmapper) Xerox RPC Superservers: servidores que escutam em várias portas. inetd em UNIX) Servidores sequenciais vs. concorrentes: lidar com um cliente de cada vez vs. existe um mapeamento um-para-um entre porta e serviço. Suporte de Sistemas de Operação para Sistemas Distribuídos 16 / 21 . múltiplos clientes Fernando Silva (DCC-FCUP) 3.Servidores: organização geral Modelo básico: um servidor é um processo que espera a chegada de pedidos de serviços num endereço determinado.e.

o pedido correspondente fica em espera Necessário que o SO suporte scheduling de threads com prioridade-elevada Solução 2: usar as facilidades de comunicação out-of-band da camada de transporte: Exemplo: o TCP permite o envio de mensagens urgentes na mesma ligação a recepção de mensagens urgentes no servidor. Suporte de Sistemas de Operação para Sistemas Distribuídos 17 / 21 . Fernando Silva (DCC-FCUP) 3.Comunicação out-of-bound Será possível interromper um servidor após ter aceite um pedido de um serviço? Solução 1: usar uma porta separada para dados urgentes (possivelmente por pedido de serviço): o servidor tem um thread à espera de mensagens com pedidos urgentes quando a mensagem urgente chega. faz com que este seja interrompido (pelo SO) para que possa lidar com as mensagens.

por exemplo. o servidor não pode antecipar comportamentos do cliente (e. servidor Web): Não lembrar se um ficheiro foi aberto (fecha-o após acesso) Não prometer invalidação da cache de um cliente Não tomar nota dos clientes Consequências: Clientes e servidores são completamente independentes Pouco frequente ter estado inconsistente devido a avarias Pode haver perda de desempenho porque. Suporte de Sistemas de Operação para Sistemas Distribuídos 18 / 21 .g.Servidores e estado (1) Servidores sem estado: não guardam informação precisa sobre o estado de um cliente após ter lidado com o seu pedido (e.g. pré-carregar blocos do ficheiro) Fernando Silva (DCC-FCUP) 3.

permite o uso de prefetching Manter uma cache em cada cliente com cópias locais de objectos partilhados Observações: O desempenho de servidores com estado pode ser muito elevado. podemos ter dificuldades com consistência da informação. sobretudo se os clientes puderem ter cópia locais Mas em presença de avarias de servidores ou clientes. Suporte de Sistemas de Operação para Sistemas Distribuídos 19 / 21 . Fernando Silva (DCC-FCUP) 3.g. servidor de ficheiros): Manter informação sobre um ficheiro aberto.Servidores e Estado (2) Servidores com estado: mantêm informação (estado) sobre interacções em curso com clientes (sessões) (e.

geralmente.Servidores Cluster Na maioria dos casos. responsável pela entrega do pedido ao servidor apropriado. servidores cluster estão organizados em três níveis diferentes: Logical switch (possibly multiple) Application/compute servers Distributed file/database system Client requests Dispatched request First tier Second tier Third tier Importante: o primeiro nível é. Fernando Silva (DCC-FCUP) 3. Suporte de Sistemas de Operação para Sistemas Distribuídos 20 / 21 .

pode vir a tornar-se um bottleneck Solução: existem várias. uma popular é TCP-handout Logically a single TCP connection Response Server Client Request Switch Request (handed off) Server Fernando Silva (DCC-FCUP) 3. Suporte de Sistemas de Operação para Sistemas Distribuídos 21 / 21 .Lidar com pedidos Ter o primeiro nível a lidar com todas as comunicações de e para o cluster.