Distributed Systems Principles and Paradigms Maarten van Steen VU Amsterdam, Dept. Computer Science (Tradução e Adaptação Ricardo Anido - IC/Unicamp) Capítulo 03: Processos Versão: 20 de março de 2014
2 / 33 Conteúdo 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: Distribuição de Sistemas Baseados em Objetos 11: Sistemas de Arquivos Distribuídos 12: Sistemas Distribuídos Baseados na Web 13: Sistemas Distribuídos Baseados em Coordenação
3.1 Processos 3 / 33 Introdução a Threads Ideia básica Construir processadores virtuais em 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 cujo contexto uma série 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.
3.1 Processos 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.) 4 / 33
3.1 Processos 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.) 4 / 33
3.1 Processos 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.) 4 / 33
5 / 33 Troca de contexto Processsos 3.1 Processos Observações 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 é geralmente mais cara, envolve chamada de sistema. 3 Criar de destruir threads é muito mais barato do que criar e destruir processos.
3.1 Processos 6 / 33 Threads e Sistemas Operacionais Ponto principal Kernel de OS deve prover threads, ou threads devem ser implementadas em bilbiotecas em nível de usuário? Solução em espaço de usuário Todas as operações podem ser completamente realizadas dentro de um único processo implementações podem ser muito eficientes. Todos os serviços disponibilizados pelo kernel são feitos em 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?
3.1 Processos 7 / 33 Threads e Sistemas Operacionais Solução 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 thread dentro do mesmo processo. Tratamento de eventos externos é simples kernel (que captura todos os eventos) escolhe a thread associada ao evento. O problema é perda de desempenho devido ao fato de overhead introduzido por chamadas de systema. Conclusão Seria ideal ter um sistema de threads híbrido, implementado em nível de usuário e de kernel.
3.1 Processos Threads Solaris Ideia básica Introduziu uma abordagem em dois níveis: processos lightweight que podem executar threads de usuário. Thread state User space Thread Kernel space Lightweight process LWP executing a thread 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. 8 / 33
3.1 Processos 9 / 33 Threads e Sistemas Distribuídos Cliente Web Multithreaded Escondendo latências de rede: Navegador Web percorre página HTML, e descobre que mais arquivos devem ser buscados. Cada arquivo é buscado usando uma thread separada, cada uma executando uma requisião HTTP (bloqueante). À medida que arquivos chegam, navegador mostra na tela. Multiplas chamadas request-reply para outras máquinas (RPC) Cliente executa várias chamadas ao mesmo tempo, cada uma usando uma thread distinta. Espera até que todos os resultados sejam retornados. Nota: se chamadas são para servidores diferentes, podemos ter uma melhora de desempenho (speed-up) linear.
3.1 Processos 10 / 33 Threads e Sistemas Distribuídos Melhora de desempenho Criar thread é muito mais barato do que criar processo. Servidor com uma única thread inibe escalabilidade mesmo em caso simples de sistema com múltiplos processadores. Em clientes: esconder latência de rede reagindo 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 de chamadas bloqueantes simplifica estrutura geral. Programas com múltiplas thread tendem a ser menores e mais fáceis de entender e depurar devido ao fluxo simplificado de controle.
11 / 33 Virtualização Processsos 3.2 Virtualização Observação Virtualização tem se tornado cada vez mais importante: Hardware muda mais rapidamente do que software Facilidade de portabilidade e migração de código Isolamento de componentes falhos ou invadidos Program Program Interface A Hardware/software system A Interface A Implementation of mimicking A on B Interface B Hardware/software system B (a) (b)
12 / 33 Arquitetura de VMs Processsos 3.2 Virtualização Observação Virtualização pode ser realizada em níveis distintos, dependendo fortemente das interfaces oferecidas pelos vários componentes: Library functions System calls Privileged instructions Application Library Operating system Hardware General instructions
3.2 Virtualização VMs de processo x VMs de arquitetura Application Runtime system Runtime system Runtime system Applications Operating system Operating system Operating system Operating system Virtual machine monitor Hardware (a) Hardware (b) 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 instruções + interfaces de dispositivos) um sistema operacional completo e suas aplicações podem ser providos (Exemplo: VMware, VirtualBox). 13 / 33
14 / 33 Processsos 3.2 Virtualização VM de arquitetura e sistemas operacionais Na prática Há vários exemplos de VMs rodando em cima de sistemas operacionais. Executam traduçã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 com ações sensíveis: chamadas a sistema, instruções privilegiadas. Ações sensíveis são trocadas por chamadas ao sistema da VM.
3.3 Clientes 15 / 33 Clientes: Interfaces de usuário Essência A maior parte de software no lado do cliente é focado em interfaces (gráficas) de usuário. Application server Application server User's terminal Window manager Xlib Local OS Application Xlib Local OS Xlib interface X protocol X kernel Device drivers Terminal (includes display keyboard, mouse, etc.)
3.3 Clientes 16 / 33 Clientes: Interfaces de usuário Documentos compostos Interface de usuário é application-aware comunicação entre aplicativos: drag-and-drop: mover objetos na tela para invocar interação 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)
17 / 33 Software Client-Side Processsos 3.3 Clientes Geralmente implementados para transparência de distribuição transparência 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 Server 1 Server 2 Server 3 Client appl. Server appl Server appl Server appl Client side handles request replication Replicated request transparência de falhas: frequentemente podem ser colocadas somente no cliente (tentativa de mascarar falhas do servidor ou de comunicação).
3.4 Servers 18 / 33 Servidores: Organização Geral Modelo Básico 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
19 / 33 Processsos 3.4 Servers Servidores: Organização 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.
3.4 Servers Comunicação fora-de-banda Ponto É possível interromper um servidor depois que ele aceitou (ou está prestes a aceitar) uma requisição de serviço? Solução 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. tenha suporte escalonamento baseado em prioridades. Solução 2 Uso de comunicação fora-de-banda da camada de transporte: Exemplo: TCP permite mensagens urgentes na mesma conexão Mensagens urgentes podem ser capturadas com uso de signals no S.O. 20 / 33
3.4 Servers Comunicação fora-de-banda Ponto É possível interromper um servidor depois que ele aceitou (ou está prestes a aceitar) uma requisição de serviço? Solução 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. tenha suporte escalonamento baseado em prioridades. Solução 2 Uso de comunicação fora-de-banda da camada de transporte: Exemplo: TCP permite mensagens urgentes na mesma conexão Mensagens urgentes podem ser capturadas com uso de signals no S.O. 20 / 33
3.4 Servers Comunicação fora-de-banda Ponto É possível interromper um servidor depois que ele aceitou (ou está prestes a aceitar) uma requisição de serviço? Solução 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. tenha suporte escalonamento baseado em prioridades. Solução 2 Uso de comunicação fora-de-banda da camada de transporte: Exemplo: TCP permite mensagens urgentes na mesma conexão Mensagens urgentes podem ser capturadas com uso de signals no S.O. 20 / 33
3.4 Servers 21 / 33 Servidores e Estado Servidores sem estado (stateless) Nunca precisam manter informação precisa sobre o cliente após tratar uma requisição: Não lembram se um arquivo foi aberto (simplesmente fecham o arquivo após acesso) Não prometem invalidar cache de cliente Não mantém quem são os clientes Consequências Clientes e servidores são completamente independentes Inconsistências de estado devido a falhas (crash) no cliente ou servidor são reduzidas Possível perda de desempenho devido, p.ex., servidor não poder antecipar comportamento do cliente (exemplo, prefetching de blocos de arquivos)
3.4 Servers 21 / 33 Servidores e Estado Servidores sem estado (stateless) Nunca precisam manter informação precisa sobre o cliente após tratar uma requisição: Não lembram se um arquivo foi aberto (simplesmente fecham o arquivo após acesso) Não prometem invalidar cache de cliente Não mantém quem são os clientes Consequências Clientes e servidores são completamente independentes Inconsistências de estado devido a falhas (crash) no cliente ou servidor são reduzidas Possível perda de desempenho devido, p.ex., servidor não poder antecipar comportamento do cliente (exemplo, prefetching de blocos de arquivos)
3.4 Servers Servidores e Estado Question Comunicação orientada a conexão casa com projeto stateless? 22 / 33
3.4 Servers 23 / 33 Servidores e Estado Servidores Stateful Mantém 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ópias locais de dados compartilhados Observação O desempenho de servidores stateful pode ser excelente, desde que clientes possam manter cópias locais. Confiabilidade não é um grande problema.
3.4 Servers 23 / 33 Servidores e Estado Servidores Stateful Mantém 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ópias locais de dados compartilhados Observação O desempenho de servidores stateful pode ser excelente, desde que clientes possam manter cópias locais. Confiabilidade não é um grande problema.
3.4 Servers 24 / 33 Clusters de servidores: três 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.
25 / 33 Processsos Tratamento de requisições 3.4 Servers Observação Fazer o primeiro nível tratar todas as comunicações do/para o cluster pode levar a gargalo. Solução Várias, mas uma popular é TCP-handoff Logically a single TCP connection Response Server Client Request Switch Request (handed off) Server
26 / 33 Migração de Código Processsos 3.5 Migração de Código Abordagem para migração de código Migração e recursos locais Migração e sistemas heterogêneos
27 / 33 Processsos 3.5 Migração de Código Migração de Código: um pouco de contexto Before execution After execution Client Server Client Server code code C/S state state* resource resource code code RemoteEval state state* resource resource code code CodeOnDemand state state* resource resource code code MobAgents state state* resource resource resource resource
28 / 33 Processsos Mobilidade Forte e Fraca 3.5 Migração de Código Componentes de objetos Code segment: contém o código Data segment: contém o estado Execution state: contém o contexto da thread executando o objeto
3.5 Migração de Código 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 Distingue code shipping (push) de code fetching (pull) Mobilidade Forte Mover componente, incluindo estado de execução Migração: mover objeto inteiro de uma máquina para outra Cloning: iniciar um clone, e colocá-lo no mesmo estado de execução 29 / 33
3.5 Migração de Código Gerenciando recursos locais Problema Um objeto usa recursos locais que podem ou não estar disponíveis na máquina alvo. Ligação recurso-máquina (Tipos de recursos) Fixo: recurso não 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) 30 / 33
31 / 33 Processsos Gerenciando recursos locais 3.5 Migração de Código Ligação processo-recurso Por identificador: o processo requer uma instância 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)
3.5 Migração de Código 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ência global MV = Mover o recurso CP = Copiar o valor do recurso RB = Re-ligar a um recurso disponível localmente 32 / 33
33 / 33 Processsos 3.5 Migração de Código Migração em sistemas heterogêneos Problema principal A máqunia alvo pode não ser adequada 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 Única solução Usar uma máquina abstrata que é implementada em plataformas diferentes: Linguagens interpretadas, efetivamente tendo sua própria VM VM Virtuais (como discutido anteriormente)