Distributed Systems Principles and Paradigms

(1)

Distributed Systems

Principles and Paradigms

Maarten van Steen

VU Amsterdam, Dept. Computer Science (Traduç ão e Adaptaç ão Ricardo Anido - IC/Unicamp)

(2)

Conte ´udo

Cap´ıtulo 01: Introduç ão 02: Arquiteturas 03: Processos 04: Comunicaç ão 05: Nomeaç ão 06: Sincronizaç ão

07: Consist ência & Replicaç ão 08: Toler ância a Falhas 09: Securança

10: Distribuic¸ ˜ao de Sistemas Baseados em Objetos 11: Sistemas de Arquivos Distribu´ıdos

12: Sistemas Distribu´ıdos Baseados na Web

13: Sistemas Distribu´ıdos Baseados em Coordenac¸ ˜ao

(3)

Processsos 3.1 Processos

Introduc¸ ˜ao a Threads

Ideia b ´asica

Construirprocessadores virtuaisem software, usando processadores f´ısicos:

Processador: prov ê um conjunto de instruç ões e mecanismos para executar

uma s érie dessas instruç ões

Thread: Um processador m´ınimo em software em cujocontextouma s ´erie

de instruç ões s ão executadas. Salvar o contexto de uma thread implica parar a execuç ão corrente e salvar todos os dados necess ários para retomar a execuç ão posteriormente.

Processo: Um processador em software em que uma ou mais threads

podem ser executadas. Executar uma thread significa executar uma s érie de instruç ões no contexto dessa thread.

(4)

Troca de contexto

Contextos

Contexto de processador: Conjunto m´ınimo de valores armazenados nos registros de um processador, usados para execuç ão de uma sequ ência de instruç ões (apontador de pilha, apontador de programa, registradores gerais, etc.)

Contexto de Thread: Conjunto m´ınimo de valores armazenados em registradores e mem ória, usados para execuç ão de uma sequ ência de instruç ões (contexto de processador, estado da pilha, etc.)

Contexto de Processo: Conjunto m´ınimo de valores armazenados em registradores e mem ória, usados para execuç ão de uma sequ ência de instruç ões (contexto de thread, registradores de ger ência de mem ória (MMU), etc.)

(5)

Troca de contexto

Contextos

(6)

Troca de contexto

Contextos

(7)

Troca de contexto

Observac¸ ˜oes

1 _{Threads compartilham o mesmo espaço de endereçamento.} Troca de contexto pode ser feita independente do systema operacional, em c ódigo de usu ário.

2 _{Troca de processos ´e geralmente mais cara, envolve chamada de} sistema.

3 _{Criar de destruir threads ´e muito mais barato do que criar e} destruir processos.

(8)

Threads e Sistemas Operacionais

Ponto principal

Kernel de OS deve prover threads, ou threads devem ser implementadas em bilbiotecas em n´ıvel de usu ´ario?

Soluç ão em espaço de usu ário

Todas as operaç ões podem ser completamente realizadasdentro de um único processo⇒ implementaç ões podem ser muito eficientes.

Todosos serviços disponibilizados pelo kernel s ão feitosem nome do processo em que a thread reside⇒ se o kernel decide bloquear uma thread, todo o processo ser á bloqueado (todas as outras threads desse processo ser ão bloqueadas).

Threads s ão usadas quando h á muitos eventos externos: threads bloqueiam com base em eventos⇒ se o kernel n ão distingue threads, como pode sinalizar eventos para uma determinada thread?

(9)

Threads e Sistemas Operacionais

Soluc¸ ˜ao no Kernel

Ideia é que kernel contenha implementaç ão de threads; todos os serviços de thread feitos a partir de chamadas a sistemas

Operaç ões que bloqueiam uma thread n ão s ão mais problema:kernel pode escolher outra threaddentro do mesmo processo.

Tratamento de eventos externos ´e simpleskernel(que captura todos os eventos)escolhe a thread associada ao evento.

O problema ´eperda de desempenhodevido ao fato de overhead introduzido por chamadas de systema.

Conclus ˜ao

Seria ideal ter um sistema de threads h´ıbrido, implementado em n´ıvel de usu ´ario e de kernel.

(10)

Threads Solaris

Ideia b ´asica

Introduziu uma abordagem em dois n´ıveis: processos lightweightque podem executar threads de usu ´ario.

Lightweight process Thread Kernel space User space LWP executing a thread Thread state Nota

Este conceito foi abandonado; hoje em dia implementaç ão é no n´ıvel de usu ário (como em java) ou no n´ıvel de kernel.

(11)

Threads e Sistemas Distribu´ıdos

Cliente Web Multithreaded

Escondendo lat ˆencias de rede:

Navegador Web percorre p ´agina HTML, e descobre quemais arquivos devem ser buscados.

Cada arquivo ´e buscado usando uma thread separada, cada uma executando uma requisi ˜ao HTTP (bloqueante).

`

A medida que arquivos chegam, navegador mostra na tela. Multiplas chamadas request-reply para outras m ´aquinas (RPC)

Cliente executa v ´arias chamadas ao mesmo tempo, cada uma usando uma thread distinta.

Espera at ´e que todos os resultados sejam retornados.

Nota: se chamadas s ˜ao para servidores diferentes, podemos ter uma melhora de desempenho (speed-up)linear.

(12)

Threads e Sistemas Distribu´ıdos

Melhora de desempenho

Criar thread ´emuitomais barato do que criar processo.

Servidor com uma ´unica thread inibe escalabilidade mesmo em caso simples desistema com m ´ultiplos processadores.

Em clientes: esconder lat ência de redereagindo a pr óxima requisiç ão enquanto anterior n ão é respondida.

Melhor estrutura

Maioria de servidores t êm demanda alta de E/S. Uso de modelo simples e bem-conhecido dechamadas bloqueantessimplifica estrutura geral. Programas com m últiplas thread tendem a sermenores e mais f áceis de entender e depurardevido aofluxo simplificado de controle.

(13)

Processsos 3.2 Virtualizac¸ ˜ao

Virtualizac¸ ˜ao

Observac¸ ˜ao

Virtualizaç ãotem se tornado cada vez mais importante: Hardwaremuda mais rapidamentedo que software Facilidade deportabilidadee migraç ão de c ódigo Isolamentode componentes falhos ou invadidos

(14)

Arquitetura de VMs

Observac¸ ˜ao

Virtualizaç ão pode ser realizada em n´ıveis distintos, dependendo fortemente dasinterfacesoferecidas pelos v ários componentes:

(15)

VMs de processo x VMs de arquitetura

Runtime system Runtime system Hardware Operating system Hardware Operating system Operating system Operating system Applications

Virtual machine monitor

(a) (b)

Runtime system Application

VM de Processos:Um programa compilado para um c ódigo intermedi ário (port ável), que é executado em um sistema de execuç ão (Exemplo: Java VM).

VM de Arquitetura: Uma camada de software que imita uma arquitetura de hardware (conjunto de instruc¸ ˜oes + interfaces de dispositivos) ⇒ um sistema operacional completo e suas

aplicac¸ ˜oes podem ser providos (Exemplo: VMware, VirtualBox).

(16)

VM de arquitetura e sistemas operacionais

Na pr ´atica

H ´a v ´arios exemplos de VMs rodando em cima de sistemas operacionais.

Executamtraduç ão bin ária: durante execuç ão de uma aplicaç ão ou sistema operacional, traduz intruç ões da m áquina virtual para o repert ório da m áquina real.

Cuidado comaç ões sens´ıveis:chamadas a sistema,instruç ões privilegiadas.

Aç ões sens´ıveis s ão trocadas por chamadas ao sistema da VM.

(17)

Processsos 3.3 Clientes

Clientes: Interfaces de usu ´ario

Ess ˆencia

A maior parte de software no lado do cliente é focado em interfaces (gr áficas) de usu ário.

X kernel Device drivers Application Xlib Xlib interface X protocol

Terminal (includes display keyboard, mouse, etc.) Application server

Application server User's terminal

(18)

Clientes: Interfaces de usu ´ario

Documentos compostos

Interface de usu ário é application-aware ⇒ comunicaç ão entre aplicativos:

drag-and-drop: mover objetos na tela para invocar interac¸ ˜ao com outros aplicativos.

ediç ão in-place:integrar v ários aplicativos no n´ıvel de interface de usu ários (por exemplo, processamento de texto + facilidades de desenho)

(19)

Software “Client-Side’

Geralmente implementados para transpar ência de distribuiç ão

transpar ˆencia de acesso: “stubs” client-side para RPCs

transpar ência de localidade/migraç ão: deixar o software client-side manter (ou descobrir) localidade do serviço

transpar ência de replicaç ão: invocaç ões m últiplas tratadas por “stub” no cliente: Client machine

Replicated request

Server 1 Server 2 Server 3

Client side handles request replication Client appl. Server appl Server appl Server appl

transpar ência de falhas: frequentemente podem ser colocadas somente no cliente (tentativa de mascarar falhas do servidor ou de comunicaç ão).

(20)

Processsos 3.4 Servers

Servidores: Organizac¸ ˜ao Geral

Modelo B ´asico

Um servidor é um processo que espera por chegadas de requisiç ões de serviços em endereços de transporte espec´ıficos. Na pr ática, h á um mapeamento um-para-um entre uma porta e um serviço.

ftp-data 20 File Transfer [Default Data] ftp 21 File Transfer [Control] telnet 23 Telnet

24 any private mail system smtp 25 Simple Mail Transfer login 49 Login Host Protocol sunrpc 111 SUN RPC (portmapper) courier 530 Xerox RPC

(21)

Servidores: Organizac¸ ˜ao Geral

Tipos de servidores

Superservidores: Servidores que escutam em v árias portas, i.e., prov êm v ários serviços independentes. Na pr ática, quando uma requisiç ão de serviço chega, iniciam um subprocesso para tratar da requisiç ão (UNIX inetd, internet service deamon)

Servidores Iterativos vs. servidores concorrentes: Servidores iterativos podem tratar de apenas um cliente por vez, em contraste com servidores concorrentes.

(22)

Comunicac¸ ˜ao fora-de-banda

Ponto

´

E poss´ıvelinterromperum servidor depois que ele aceitou (ou est á prestes a aceitar) uma requisiç ão de serviço?

Soluc¸ ˜ao 1

Use uma porta separada para dados urgentes:

Servidor tem uma porta separada para mensagens urgentes para o processo/thread.

Mensagem urgente chega ⇒requisiç ão associada é suspensa.

Nota: exige que o S.O. tenhasuporte escalonamento baseado em

prioridades. Soluc¸ ˜ao 2

Uso de comunicaç ão fora-de-banda da camada de transporte: Exemplo: TCP permite mensagens urgentes na mesma conex ão

(23)

Comunicac¸ ˜ao fora-de-banda

Ponto

´

Soluc¸ ˜ao 1

Nota: exige que o S.O. tenhasuporte escalonamento baseado em prioridades.

Soluc¸ ˜ao 2

(24)

Comunicac¸ ˜ao fora-de-banda

Ponto

´

Soluc¸ ˜ao 1

Nota: exige que o S.O. tenhasuporte escalonamento baseado em prioridades.

Soluc¸ ˜ao 2

(25)

Servidores e Estado

Servidores sem estado (stateless)

Nunca precisam manter informaç ãoprecisasobre o cliente ap ós tratar uma requisiç ão:

N ˜ao lembram se um arquivo foi aberto (simplesmente fecham o arquivo ap ´os acesso)

N ão prometem invalidar cache de cliente N ão mant ém quem s ão os clientes Consequ ências

Clientes e servidores s ˜aocompletamente independentes

Inconsist ˆencias de estadodevido a falhas (crash) no cliente ou servidor

s ˜ao reduzidas

Poss´ıvelperda de desempenhodevido, p.ex., servidor n ˜ao poder

antecipar comportamento do cliente (exemplo, prefetching de blocos de arquivos)

(26)

Servidores e Estado

Servidores sem estado (stateless)

Nunca precisam manter informaç ãoprecisasobre o cliente ap ós tratar uma requisiç ão:

N ˜ao lembram se um arquivo foi aberto (simplesmente fecham o arquivo ap ´os acesso)

N ão prometem invalidar cache de cliente N ão mant ém quem s ão os clientes Consequ ências

Clientes e servidores s ˜aocompletamente independentes

Inconsist ˆencias de estadodevido a falhas (crash) no cliente ou servidor

s ˜ao reduzidas

Poss´ıvelperda de desempenhodevido, p.ex., servidor n ˜ao poder antecipar comportamento do cliente (exemplo, prefetching de blocos de arquivos)

(27)

Servidores e Estado

Question

Comunicaç ão orientada a conex ão “casa” com projeto stateless?

(28)

Servidores e Estado

Servidores Stateful

Mant ´em estado de clientes:

Registra que arquivo foi aberto (pre-fetching pode ser feito) Sabe que dados o cliente tem no cache, e permite que clientes mantenham c ´opias locais de dados compartilhados

Observac¸ ˜ao

Odesempenho de servidores stateful pode ser excelente, desde que

clientes possam manter c ópias locais. Confiabilidade n ão é um grande

problema.

(29)

Servidores e Estado

Servidores Stateful

Mant ´em estado de clientes:

Registra que arquivo foi aberto (pre-fetching pode ser feito) Sabe que dados o cliente tem no cache, e permite que clientes mantenham c ´opias locais de dados compartilhados

Observac¸ ˜ao

Odesempenho de servidores stateful pode ser excelente, desde que clientes possam manter c ópias locais. Confiabilidade n ão é um grande problema.

(30)

Clusters de servidores: tr ˆes n´ıveis (tiers) distintos

Logical switch (possibly multiple)

Application/compute servers Distributed file/database

system

Client requests

Dispatched request

First tier Second tier Third tier

Elemento crucial

O primeiro n´ıvel é em geral respons ável por passar requisiç ões para o servidor apropriado.

(31)

Tratamento de requisic¸ ˜oes

Observac¸ ˜ao

Fazer o primeiro n´ıvel tratar todas as comunicac¸ ˜oes do/para o cluster pode levar agargalo.

Soluc¸ ˜ao

V ´arias, mas uma popular ´eTCP-handoff

Switch Client

Server

Server Request _{(handed off)}Request

Response Logically a

single TCP connection

(32)

Processsos 3.5 Migraç ão de C ódigo

Migraç ão de C ódigo

Abordagem para migraç ão de c ódigo Migraç ão e recursos locais

Migraç ão e sistemas heterog êneos

(33)

Migraç ão de C ódigo: um pouco de contexto

Before execution After execution Client Server Client Server

(34)

Mobilidade Forte e Fraca

Componentes de objetos

Code segment: cont ém o c ódigo Data segment: cont ém o estado

Execution state: cont ´em o contexto da thread executando o objeto

(35)

Mobilidade Forte e Fraca

Mobilidade Fraca

Mover apenas segmentos de c ódigo e dados (e reinicia execuç ão): Relativamente simples, se c ódigo é port ável

Distinguecode shipping(push) decode fetching(pull)

Mobilidade Forte

Mover componente, incluindo estado de execuc¸ ˜ao

Migraç ão: mover objeto inteiro de uma m áquina para outra Cloning: iniciar um clone, e coloc á-lo no mesmo estado de execuç ão

(36)

Gerenciando recursos locais

Problema

Um objeto usa recursos locais que podem ou n ˜ao estar dispon´ıveis na m ´aquina alvo.

Ligaç ão recurso-m áquina (Tipos de recursos)

Fixo: recurso n ˜ao pode ser migrado, como hardware local (p. ex. de criptografia)

Colado (Fastened): recurso pode ser movido, mas custa caro Descolado (Unattached): recurso pode ser facilmente migrado junto com objeto (p. ex. cache)

(37)

Gerenciando recursos locais

Ligac¸ ˜ao processo-recurso

Por identificador: o processo requer uma inst ˆancia espec´ıfica do recurso (p.ex. um banco de dados espec´ıfico)

Por valor: o processo requer o valor de um recurso (p.ex. um conjunto de entradas do cache)

Por tipo: o processo requer apenas que um recurso de tipo espec´ıfico seja dispon´ıvel (p.ex. uma tela colorida)

(38)

Gerenciando recursos locais

Descolado Colado Fixo

ID MV (or GR) GR (or MV) GR

Valor CP (or MV, GR) GR (or CP) GR

Tipo RB (or MV, GR) RB (or GR, CP) RB (or GR)

GR = Estabelecer refer ˆencia global MV = Mover o recurso

CP = Copiar o valor do recurso

RB = Re-ligar a um recurso dispon´ıvel localmente

(39)

Migraç ão em sistemas heterog êneos

Problema principal

A m áqunia alvo pode n ão seradequada para executar o c ódigo migrado

A definiç ão de contexto de processo/thread/processador é altamente dependente do hardware local, sistema operacional e sistema de execuç ão

´

Unica soluc¸ ˜ao

Usar umam ´aquina abstrataque ´e implementada em plataformas diferentes:

Linguagens interpretadas, efetivamente tendo sua pr ´opria VM VM Virtuais (como discutido anteriormente)