3.

Suporte de Sistemas de Operao para Sistemas Distribudos

Fernando Silva
DCC-FCUP

Fernando Silva (DCC-FCUP)

3. Suporte de Sistemas de Operao para Sistemas Distribudos

1 / 21

Agenda
Suporte necessrio para middleware e Sistemas Distribudos Implementao de threads Virtualizao Clientes Servidores Servidores cluster

Referncia: slides e cap. 3 do livro de Andrew Tanenbaum e Maarten van Steen.

Fernando Silva (DCC-FCUP)

3. Suporte de Sistemas de Operao para Sistemas Distribudos

2 / 21

Suporte necessrio para middleware e SD

Os sistemas operativos desempenham um papel fundamental no suporte ao funcionamento dos sistemas distribudos: Coordenam recursos bsicos como:
processos, memria, disco, comunicao

Fornecem uma API de programao para acesso aos recursos, que

garante proteco dos recursos usados pelas aplicaes processamento concorrente de aplicaes

Acesso a uma rede de comunicao

Fernando Silva (DCC-FCUP)

3. Suporte de Sistemas de Operao para Sistemas Distribudos

3 / 21

Processos (1)
Os processos so um construtor fundamental para os sistemas distribudos. Processo - programa em execuo (um uxo de execuo)
caracterizado por um espao de endereamento e um contexto (ambiente de execuo e estado do processo guardado em registos e memria)

Troca de contexto
sempre que o SO comuta a execuo de dois processos tem custos bvios (overheads)

Fernando Silva (DCC-FCUP)

3. Suporte de Sistemas de Operao para Sistemas Distribudos

4 / 21

Processos e Threads
A funo de um SO tornar transparente a execuo de mltiplos processos que concorrem pela partilha do mesmo CPU, s que tem custos: gesto segmentos de memria independentes overheads das trocas de contexto swapping de processos entre memria e disco O que necessrio? possibilitar ter vrios uxos de execuo comutao rpida e de baixo custo entre os vrios uxos de execuo Soluo: threads
Fernando Silva (DCC-FCUP) 3. Suporte de Sistemas de Operao para Sistemas Distribudos 5 / 21

Threads versus mltiplos processos

Criao e destruio de threads muito mais eciente do que com processos
criao aproximadamente 10-20 vezes mais eciente

Threads de um processo:
partilham o mesmo espao de endereamento trocas de contexto entre threads realizadas sem interveno do OS (5-50 vezes mais eciente) partilham dados e outros recursos no esto protegidos uns dos outros

Uso de mltiplos threads permite usar concorrncia para

esconder a latncia da comunicao melhorar desempenho (e.g. nos servidores) melhorar usabilidade (e.g. nos clientes)

Fernando Silva (DCC-FCUP)

3. Suporte de Sistemas de Operao para Sistemas Distribudos

6 / 21

Implementao de threads (1)

Deve a implementao ser feita a nvel do kernel do SO ou em software no nvel do utilizador? User-level: todas as operaes podem ser internas a um nico processo resulta em implementaes muito ecientes todos os servios fornecidos pelo kernel so concretizados em nome do processo onde reside o thread se o kernel decidir bloquear o thread, ento todo processo bloqueia. Solues complicadas. interessam-nos os threads para lidar com eventos externos (bloqueiam com base no evento) se o kernel no os distingue, como suportar sinalizao de eventos?

Fernando Silva (DCC-FCUP)

3. Suporte de Sistemas de Operao para Sistemas Distribudos

7 / 21

Implementao de threads (2)

Kernel-level: operaes de bloqueio de threads no constituem problema: o scheduler selecciona para execuo, outro thread do mesmo processo. fcil de lidar com eventos externos: o kernel (que apanha todos os eventos) selecciona para execuo o thread associado ao evento. problema: perde-se ecincia porque cada operao de um thread requer passagem (trap) da aplicao para o kernel. Concluso: abordagens hbridas user-level e kernel-level.

Fernando Silva (DCC-FCUP)

3. Suporte de Sistemas de Operao para Sistemas Distribudos

8 / 21

Implementao de threads (3)

Solaris threads so um exemplo de modelo hbrido. Light-Weight Processes (LWP) - processos leves que executam no contexto de um processo (no kernel) user-level threads - com todas as operaes e sincronizao sem interveno do kernel os LWPs
tm o seu scheduler e partilham uma tabela de threads sincronizam no acesso tabela, sem suporte do kernel executam operaes bloqueantes pelos threads em modo kernel
Thread state User space Thread

Lightweight process Kernel space LWP executing a thread

Fernando Silva (DCC-FCUP)

3. Suporte de Sistemas de Operao para Sistemas Distribudos

9 / 21

Concorrncia em SDs: clientes

Os threads permitem satisfazer chamadas de sistema bloqueantes sem bloquear o processo que executa os threads.
propriedade excelente para expressar comunicao mantendo mltiplas ligaes lgicas em simultneo.

Clientes multithreaded - objectivo sobrepor comunicao e processamento Exemplo: cliente Web multithreaded (browser)
ao carregar uma pgina HTML, o browser analisa-a e verica que necessrio carregar outros objectos (e.g. imagens) cada objecto ou cheiro carregado por um thread distinto, cada um atravs de um pedido HTTP (bloqueante) o browser vai visualizando os cheiros medida que estes vo chegando.

Fernando Silva (DCC-FCUP)

3. Suporte de Sistemas de Operao para Sistemas Distribudos

10 / 21

Concorrncia em SDs: servidores

Objectivo melhorar o desempenho e estrutura. mltiplos threads para atender pedidos reagir a novos pedidos enquanto anteriores esto a ser satisfeitos mapevel em sistemas multiprocessador (ou multicore) programas de compreenso mais simples Modelo dispatcher/worker (gura)

Fernando Silva (DCC-FCUP)

3. Suporte de Sistemas de Operao para Sistemas Distribudos

11 / 21

Virtualizao
A virtualizao de recursos cada vez mais importante, pois permite que os sistemas sejam independentes do hardware sejam facilmente portveis e o cdigo migrvel quem isolados de falhas ou ataques a componentes suportem legacy software No essencial, a virtualizao permite substituir interfaces existentes de modo a imitar o comportamento de outro sistema.
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. Suporte de Sistemas de Operao para Sistemas Distribudos 12 / 21

Implementaes da virtualizao (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 cdigo intermdio (portvel) que executado por um emulador (E.g. Java VM) VM Monitor (b): camada independente de software que imita o conjunto de instrues do hardware permite a execuo concorrente e independente de mltiplos SOs (E.g. VMware, Xen, VirtualBox)
Fernando Silva (DCC-FCUP) 3. Suporte de Sistemas de Operao para Sistemas Distribudos 13 / 21

Clientes: interfaces com utilizador

A grande maioria do software do lado do cliente orientado para as interfaces grcas com o utilizador (cada vez mais temos thin-clients).
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, mouse, etc.)

Interfaces mais modernas permitem interaco com a aplicao (documentos compostos) comunicao entre aplicaes. drag-and-drop: movimento de objectos pode originar interaco com outras aplicaes (e.g. mover o cone do cheiro para o cesto do lixo) in-place editing: integrao de vrias aplicaes na interface (e.g. processamento de texto e desenho)
Fernando Silva (DCC-FCUP) 3. Suporte de Sistemas de Operao para Sistemas Distribudos 14 / 21

Software do lado do cliente

Mais do que apenas interface com utilizador, pode incluir processamento local e comunicao.
Software embebido nas ATMs, caixas registadoras, TV powerboxes, etc.

Inclui componentes para alcanar transparncia na distribuio

transparncia no acesso: stubs para RPC transparncia na localizao/migrao: cliente conhece localizao do servidor e informado se esta mudar transparncia na replicao: mltiplas invocaes pelo stub do client. transparncia na falha: tentativas automticas de ligao para o mesmo ou outro servidor
Client machine Client appl. Server 1 Server appl Server 2 Server appl Server 3 Server appl

Client side handles request replication

Replicated request

Fernando Silva (DCC-FCUP)

3. Suporte de Sistemas de Operao para Sistemas Distribudos

15 / 21

Servidores: organizao geral

Modelo bsico: um servidor um processo que espera a chegada de pedidos de servios num endereo determinado. Na prtica, existe um mapeamento um-para-um entre porta e servio.
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 vrias portas, i.e. fornecem vrios servios independentes (e.g. inetd em UNIX) Servidores sequenciais vs. concorrentes: lidar com um cliente de cada vez vs. mltiplos clientes
Fernando Silva (DCC-FCUP) 3. Suporte de Sistemas de Operao para Sistemas Distribudos 16 / 21

Comunicao out-of-bound
Ser possvel interromper um servidor aps ter aceite um pedido de um servio? Soluo 1: usar uma porta separada para dados urgentes (possivelmente por pedido de servio):
o servidor tem um thread espera de mensagens com pedidos urgentes quando a mensagem urgente chega, o pedido correspondente ca em espera Necessrio que o SO suporte scheduling de threads com prioridade-elevada

Soluo 2: usar as facilidades de comunicao out-of-band da camada de transporte:

Exemplo: o TCP permite o envio de mensagens urgentes na mesma ligao a recepo de mensagens urgentes no servidor, faz com que este seja interrompido (pelo SO) para que possa lidar com as mensagens.
Fernando Silva (DCC-FCUP) 3. Suporte de Sistemas de Operao para Sistemas Distribudos 17 / 21

Servidores e estado (1)

Servidores sem estado: no guardam informao precisa sobre o estado de um cliente aps ter lidado com o seu pedido (e.g. servidor Web): No lembrar se um cheiro foi aberto (fecha-o aps acesso) No prometer invalidao da cache de um cliente No tomar nota dos clientes Consequncias: Clientes e servidores so completamente independentes Pouco frequente ter estado inconsistente devido a avarias Pode haver perda de desempenho porque, por exemplo, o servidor no pode antecipar comportamentos do cliente (e.g. pr-carregar blocos do cheiro)

Fernando Silva (DCC-FCUP)

3. Suporte de Sistemas de Operao para Sistemas Distribudos

18 / 21

Servidores e Estado (2)

Servidores com estado: mantm informao (estado) sobre interaces em curso com clientes (sesses) (e.g. servidor de cheiros): Manter informao sobre um cheiro aberto, permite o uso de prefetching Manter uma cache em cada cliente com cpias locais de objectos partilhados Observaes: O desempenho de servidores com estado pode ser muito elevado, sobretudo se os clientes puderem ter cpia locais Mas em presena de avarias de servidores ou clientes, podemos ter diculdades com consistncia da informao.

Fernando Silva (DCC-FCUP)

3. Suporte de Sistemas de Operao para Sistemas Distribudos

19 / 21

Servidores Cluster
Na maioria dos casos, servidores cluster esto organizados em trs nveis 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 nvel , geralmente, responsvel pela entrega do pedido ao servidor apropriado.

Fernando Silva (DCC-FCUP)

3. Suporte de Sistemas de Operao para Sistemas Distribudos

20 / 21

Lidar com pedidos

Ter o primeiro nvel a lidar com todas as comunicaes de e para o cluster, pode vir a tornar-se um bottleneck Soluo: existem vrias, 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 Operao para Sistemas Distribudos

21 / 21